Introduction

Program

• Program is collection of instruction code in which there will be source code and object code.

S/w document

• As software development is multi-phase process, so after completing all the phases a document is created.
• For each phases we have to create a separate software document. Some of the phases document are mentioned below.
• SRS (Software Requirement Specification) document: A comprehensive document that outlines the detailed requirements and specifications for the software project. It provides a clear description of the software's functionalities, constraints, user interactions, and system behavior.".
• Design document: Based on the software requirements, a document outlining the design of the software will be created. This document will include the architecture of the software, providing guidance for its development.
• Coding document: A coding document, also known as a source code document, is a record that documents the code implementation of a software project. It includes the code logic, algorithms, functions, classes, and any other code-related components. This document serves as a reference for developers, making it easier to understand and maintain the codebase. It might also include comments explaining the code's purpose, usage, and potential complexities.
• Test document: A test document, also called a testing plan or test specification, outlines the strategies and procedures for testing a software application. It includes details about the various types of tests to be conducted, such as unit testing, integration testing, and system testing. The document specifies test cases, expected outcomes, testing environments, and criteria for passing or failing tests. A comprehensive test document helps ensure the quality and reliability of the software by providing a structured approach to testing its functionalities and identifying potential issues.

If in future the developer team changes then they can easily refer to these documents and understand the software that they want to build.

Operating procedure

• After the software has been developed, it is essential for the developer to provide instructions to the user on its usage. This is where the operating procedure comes into play.
• Operating procedure is divided into two parts:
  1. User Manual: This manual guides users on how to effectively utilize the software, providing step-by-step instructions for various features and functions.
  2. Operational Manual: This manual specifies the technical characteristics of the software, including details such as supported devices, operating systems, versions, and other relevant technical information.

Operational Characteristics: How well the software works in operation

• Usability: This refers to how easily and effectively users can interact with the software. It includes intuitive user interfaces, clear instructions, and a pleasant user experience.
• Correctness: Software correctness implies that the software produces accurate and expected results under various conditions. It involves thorough testing and validation to ensure the absence of errors and bugs.
• Functionality: The software's functionality encompasses its intended features and capabilities. It should satisfy user requirements and perform tasks according to specifications.
• Efficiency: Efficient software executes tasks in a timely manner while making optimal use of system resources such as memory and processing power.
• Dependability: Dependable software is reliable and consistent in its behavior. It can be trusted to perform as expected without unexpected failures or crashes.
• Safety and Security: Software safety ensures that it doesn't cause harm or endanger users. Security involves protecting data from unauthorized access, ensuring the software's resistance to breaches.

Transitional Characteristics: Accommodating Platform Changes

• Portability: Portable software can be smoothly transferred or adapted to different environments or platforms without significant modifications.
• Reusability: Reusable components within the software allow for efficient development by using existing solutions, reducing redundancy, and saving time and effort.
• Adaptability: Adaptable software can be adjusted to accommodate changes in requirements, technological advancements, or new features without disrupting its overall functionality.

Maintenance Characteristics: How software adapts to changing environments

• Scalability: Scalable software can handle an increasing amount of work, users, or data. It can be expanded to support growth without significant degradation of performance.
• Flexibility: Flexible software can be modified or extended to meet changing needs. It can incorporate new features or adapt to evolving business requirements.
• Maintainability: Maintainable software is designed and structured in a way that facilitates easy updates, bug fixes, and enhancements over its lifecycle. This reduces maintenance costs and effort.

System Software

• System software directly interacts with hardware and the underlying system infrastructure.
• It provides fundamental functionalities essential for the operation of a computer system.
• Examples include text editors, web browsers, operating systems (OS), compilers, and hardware drivers.

Application Software

• Application software is designed to provide specific functionalities to users, addressing their needs and requirements.
• Examples encompass familiar applications like messaging apps (WhatsApp), social media platforms (Facebook), and antivirus software.

Engineering or Scientific Software

• This type of software caters to specialized fields such as engineering and scientific research.
• It includes software tools used for aeronautical engineering, simulations, modeling, and data analysis.

Embedded Software

• Embedded software is directly integrated into hardware devices, enhancing their functionality and capabilities.
• Examples range from air conditioners (AC) and speedometers in vehicles to consumer electronics.

Web Applications

• Web applications are accessible via web browsers and offer a wide range of functionalities and services.
• They include browser-based apps, email services like Gmail, social media platforms, and online banking applications.

AI Software

• AI (Artificial Intelligence) software is used in applications that involve pattern recognition, machine learning, and robotics.
• These software tools play a crucial role in fields like data analysis, automation, and decision-making.

Causes of Software Crisis:

• The cost of owning and maintaining software became as expensive as developing it initially.
• Many projects were running beyond their scheduled time.
• Software from that time was inefficient and not very effective.
• The quality of the software was poor, leading to unsatisfactory performance.
• Software often failed to meet the requirements of users.
• The average software project took longer than expected, usually exceeding its planned schedule by around half.
• Delivery of software was often delayed or never happened.
• Resource utilization wasn't optimized, leading to wastage.
• It was hard to make changes, fix issues, and improve software efficiently.
• The complexity of software made it difficult to modify.

Factors Contributing to the Software Crisis:

• Poor project management practices.
• Inadequate training in software engineering, leading to a lack of necessary skills.
• Project teams had members with limited skills and expertise.
• There were only minor improvements in productivity, which impacted software development efficiency.

Solution of Software Crisis:

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.

Guidelines for Preventing Software Crisis:

• Reduction in software over budget.
• The quality of software must be high.
• Less time is needed for a software project.
• Experienced and skilled people working over the software project.
• Software must be delivered.
• Software must meet user requirements.

Rapid Technology Advancement

• Technology advancement is a blessing for the IT industry. However, it creates pressure on software developers to incorporate new technology features into software.

Increasing Customer Demands

• Customer demands may change over time, leading software developers to modify the software's current status. This can affect deadlines and the cost of software development.

Time Limitations

• Software developers often work under pressured environments and need to meet project requirements within strict timelines, especially when working with international clients across different time-zones.

Limited Infrastructure/Resources

• The lack of resources or IT infrastructure affects software quality. For instance, the absence of high-performance development tools, powerful computing machines, and efficient data storage architectures can impact productivity and performance.

Conflicts with Software Testing Teams

• Interpersonal conflicts can arise between teams in a software development project due to factors like performance pressure, different mindsets, and varied job roles. Unmanaged conflicts can adversely affect the project.

Understanding Large and Complex System Requirements is Difficult

• Large system requirements may involve security constraints due to numerous users and a substantial number of functions to be implemented.
• Undefined system boundaries can lead to unnecessary functions, affecting implementation costs and budget.

Customers/Stakeholders are Not Clear About Their Needs

• Customers might be uncertain about the functionalities they want in the software.
• Changing requirements, based on successive interviews or reviews, can complicate the development process.
• Note: Software stakeholders are individuals, groups, or entities that have an interest, role, or involvement in the development and deployment of software. These stakeholders play a crucial role in influencing the software's design, functionality, and success. They contribute to various aspects of the software development lifecycle and have a vested interest in the software's outcomes.
  • Types of Software Stakeholders:
    • Users: The end-users or customers who will interact with and use the software. Their needs, preferences, and feedback are vital to ensure the software aligns with their requirements.
    • Clients/Customer Representatives: These individuals represent the interests and requirements of the organization or entity that's commissioning the software. They provide insights into the organization's needs and expectations.
    • Developers/Development Team: The individuals responsible for designing, coding, and testing the software. They work to translate stakeholder requirements into a functional product.
    • Product Managers: Responsible for overseeing the software's development and ensuring that it aligns with the organization's goals and market needs. And so on.

Solutions to Overcome Challenges in Eliciting Requirements

• Maintaining proper documentation.
• Trying to understand from a stakeholder’s perspective.
• Establishing proper communication with stakeholders.
• Identifying conflicting requirements from the stakeholder side.
• Establishing structured and insightful discussions with end-users.
• Performing proper market research and competitor analysis.

Waterfall method

• The Waterfall Model was first process model.
• It is also referred to as a Liner-Sequential Life Cycle model.
• In this each phase must be completed fully before the next phase can begin.
• This type of model is basically used for small projects and there are no uncertain requirements.
• At the end of each phase, a review takes place to determine if the project is on the right path or not.
• In this model the testing starts only after the development is complete.

classical waterfall model divides the cycle into the following phases as shown in above figure.

Prototyping

Prototyping is defined as the process of developing a working replication of a product or system that has to be engineered. It offers a small-scale facsimile of the end product and is used for obtaining customer feedback as described below:

The Prototyping Model

The Prototyping Model is one of the most popularly used Software Development Life Cycle Models (SDLC models). This model is used when the customers do not know the exact project requirements beforehand. In this model, a prototype of the end product is first developed, tested, and refined as per customer feedback repeatedly until a final acceptable prototype is achieved, which forms the basis for developing the final product.

In this process model, the system is partially implemented before or during the analysis phase, thereby giving the customers an opportunity to see the product early in the life cycle. The process starts by interviewing the customers and developing the incomplete high-level paper model. This document is used to build the initial prototype supporting only the basic functionality as desired by the customer. Once the customer figures out the problems, the prototype is further refined to eliminate them. The process continues until the user approves the prototype and finds the working model to be satisfactory. There are four types of models available:

Advantages

• The customers get to see the partial product early in the life cycle. This ensures a greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing the quality of the software.
• Flexibility in design.

Disadvantages

• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for developers to accommodate all the changes demanded by the customer.
• There is uncertainty in determining the number of iterations that would be required before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the initial prototype.

Use

The Prototyping Model should be used when the requirements of the product are not clearly understood or are unstable. It can also be used if requirements are changing quickly. This model can be successfully used for developing user interfaces, high technology software-intensive systems, and systems with complex algorithms and interfaces. It is also a very good choice to demonstrate the technical feasibility of the product.

Incremental Model

The incremental process model is also known as the Successive version model. First, a simple working system developed with a few basic features and delivered to the customer. Then thereafter many successive iterations/ versions are implemented and delivered to the customer until the desired system is released.

A, B, and C are modules of Software Products that are incrementally developed and delivered.

When to Use This Model:

• Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
• When Requirements are known up-front.
• When Projects have lengthy development schedules.
• Projects with new Technology.
• Requires good planning and design.
• The total cost is not lower.
• Well-defined module interfaces are required.

Advantages:

1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support because of its iterations.

Disadvantages:

• A good team and proper planned execution are required.
• Because of its continuous iterations, the cost increases.

RAD Model (Rapid Application Development)

RAD Model or Rapid Application Development Model is similar to the incremental model and waterfall model. In RAD Model, development should be done in a specified time frame.

RAD Model is suitable for small projects where all the requirements are gathered before starting development of the project. Once the client gives feedback, based on the client’s feedback, other changes are done. This process goes parallel with cooperation with the client and developers. Each software version is delivered to the client with working functionality, and changes are made based on the client’s feedback. Development moves faster in RAD Model with minimum errors. RAD Model follows the incremental delivery of the modules. The main goal of RAD Model is to make the reusability of the developed components.

Phases in RAD Model:

• Business Modeling
• Data Modeling
• Process Modeling
• Application Modeling
• Testing and Turnover

Advantages of RAD Model:

• Fast application development and delivery.
• Less testing activity required.
• Visualization of progress.
• Less resources required.
• Review by the client from the very beginning of development, so very less chance to miss the requirements.
• Very flexible if any changes are required.
• Cost-effective.
• Good for small projects.

Disadvantages of RAD Model:

• Highly skilled resources required.
• Client’s feedback required on each development phase.
• Automated code generation is very costly.
• Difficult to manage.
• Not a good process for long-term and big projects.
• Proper modularization of project required.

When RAD Model Should Be Followed:

• For low budget projects for which automated code generation cost is low.
• When highly skilled resources are available.
• When it’s easy to modularize the project.
• If technical risks are low.
• If development needs to be completed in a specified time.
• RAD Model is suitable if the functionality has fewer dependencies on other functionality.

Spiral Model

The Spiral model is one of the most important Software Development Life Cycle models, which provides support for Risk Handling. In its diagrammatic representation, it 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. 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, so the project manager has an important role to develop a product using the spiral model.

The Radius of the spiral at any point represents the expenses (cost) of the project so far, and the angular dimension represents the progress made so far in the current phase.

The above diagram shows the different phases of the Spiral Model:

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software project. The most important feature of the spiral model is handling these unknown risks after the project has started. Such risk resolutions are easier done by developing a prototype. The spiral model supports coping up with risks by providing the scope to build a prototype at every phase of the software development.

The Prototyping Model also supports risk handling, but the risks must be identified completely before the start of the development work of the project. But in real-life project risk may occur after the development work starts; in that case, we cannot use the Prototyping Model. In each phase of the Spiral Model, the features of the product dated and analyzed, and the risks at that point in time are identified and are resolved through prototyping. Thus, this model is much more flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For example, a single loop spiral actually represents the Iterative Waterfall Model. The spiral model incorporates the stepwise approach of the Classical Waterfall Model. The spiral model uses the approach of the Prototyping Model by building a prototype at the start of each phase as a risk-handling technique. Also, the spiral model can be considered as supporting the Evolutionary model – the iterations along the spiral can be considered as evolutionary levels through which the complete system is built.

Advantages of Spiral Model:

• 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.
• Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
• Flexibility in Requirements: Change requests in the Requirements at a later phase can be incorporated accurately by using this model.
• Customer Satisfaction: Customer 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.

Disadvantages of Spiral Model:

• Complex: The Spiral Model is much more complex than other SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it is expensive.
• 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.
• Difficulty in time management: As the number of phases is unknown at the start of the project, so time estimation is very difficult.

V-Model (Verification and Validation Model)

The V-Model, which stands for Verification and Validation Model, is a sequential path of execution of processes, similar to the waterfall model. Each phase must be completed before the next phase begins. Testing of the product is planned in parallel with a corresponding phase of development in the V-model.

Phases of the V-Model:

• Requirements: Like BRS and SRS, this phase begins the life cycle model, similar to the waterfall model. However, in this model, before development starts, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.
• High-level design (HLD): This phase focuses on system architecture and design, providing an overview of the solution, platform, system, product, and service/process. An integration test plan is created in this phase to test the pieces of the software system's ability to work together.
• Low-level design (LLD): In this phase, the actual software components are designed, defining the actual logic for each and every component of the system. A class diagram with all the methods and relations between classes comes under LLD. Component tests are created in this phase as well.
• Implementation: This is where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V, where the test plans developed earlier are now put to use.
• Testing: At the bottom of the V-Shape model, testing activities like planning and test designing happen well before coding. This saves a lot of time, leading to a higher chance of success over the waterfall model. Proactive defect tracking is enabled, and it avoids the downward flow of defects. It works well for small projects where requirements are easily understood.

Advantages of V-Model:

• Simple and easy to use.
• Testing activities like planning and test designing happen well before coding, saving time and increasing the chance of success.
• Proactive defect tracking - defects are found at an early stage.
• Avoids the downward flow of defects.
• Works well for small projects where requirements are easily understood.

Disadvantages of V-Model:

• Very rigid and least flexible.
• Software is developed during the implementation phase, so no early prototypes of the software are produced.
• If any changes happen midway, then the test documents along with requirement documents have to be updated.

When to use the V-Model:

• The V-shaped model should be used for small to medium-sized projects where requirements are clearly defined and fixed.
• The V-Shaped model should be chosen when ample technical resources are available with needed technical expertise.
• High confidence of the customer is required for choosing the V-Shaped model approach. Since no prototypes are produced, there is a very high risk involved in meeting customer expectations.