Evolutionary Models : Lecture 6

Department : MCA

Semester     : IV

Subject        : Principles of Software Engineering                                             

Paper           : 21

Faculty        : Avinash Kumar

Syllabus covered in  this blog

Evolutionary Models (Prototype & Spiral model)

Evolutionary Model

Evolutionary model is additionally spoken because of the successive versions model and sometimes because of the incremental model. In Evolutionary model, the software requirement is first counteracted into several modules (or functional units) which will be incrementally constructed and delivered.

The developer initially develops the core modules of the system. The core modules are people who don't need services from the opposite modules. The initial product sketch is upgraded into increasing levels of functional capability by adding new features in successive versions. Every evolutionary model can be developed by using the iterative model of development.

Each successive version of the product is fully functional software more capable than the previous versions.

This model is normally useful for huge products, where it is easier to find modules for incremental implementation.

Advantages of Evolutionary Model

• Evolutionary model is normally useful for very large products.
• User gets a chance to experiment with partially developed software much before the complete version of the system is released.
• Evolutionary model helps to accurately elicit user requirements during the delivery of different versions of the software.
• The core modules get tested thoroughly, thereby reducing the chances of errors in the core modules of the final products.
• Evolutionary model avoids the need to commit large resources in one go for development of the system.

Disadvantages of Evolutionary Model

• The delivery of full software can be late due to different changes by customers during development.
• It is difficult to divide the problem into several parts, that would be acceptable to the customer which can be incrementally implemented and delivered.

Types of Evolutionary Model 

• Prototype Model
• Spiral Model

 

 Prototype Model

 

A prototype is a simulation of the actual product or system. A prototype model usually exhibits limited functional capabilities, low reliability, and less efficient performance as compared to the actual software.

A prototype model is usually built using several shortcuts. The shortcuts might involve using inaccurate, inefficient or dummy functions. A prototype usually turns out to be a very crude version of the actual system.

In this model, prototyping starts with initial requirements gathering phase. Quick design is carried out and a prototype is built. The developed prototype is submitted to the customer for his assessment.

Based on the customer feedback, the requirements are refined and the prototype is suitably modified. This cycle of obtaining customer feedback and modifying the prototype continues until the customer approves the prototype.

Once the customer approves the prototype, the actual system is developed using the iterative waterfall approach.

Need for a Prototype Model in Software Development

• To illustrate the input data formats, messages, reports, and interactive dialogues to the customer.
• To gain a better understanding of the customer’s needs
• To examine the technical issues associated with product development.
• It is not possible to get the perfect product in the first attempt.
• If we want to develop a good product we must plan to throw away the first version.
• The experience acquired in developing the prototype can be used to develop the final product.

Advantages of Prototype Model

• Demo working model: Customer get demo working model of actual product which help them to give a better understanding and attain a high level of satisfaction.
• New requirement: Based on the customer feedback, the requirements are redefined and the prototype is suitably modified till final approval.
• Missing functionality: can be easily established.
• Easy error detection: It saves time and cost in developing the prototype and enhances the quality of the final product.
• Flexibility: in the development phase.

Disadvantages of Prototype Model

• Time-consuming: As the prototype is being modified time to time according to customer requirement which usually increases the time of completion of the product.
• Complexity: Change in the requirement usually expands the scope of the product beyond its original plan and thus increase the complexity.
• Poor Documentation: Continuous changing of requirement can lead to poor documentation.
• Unpredictability of no of iteration: It is difficult to determine the no of iteration required before the prototype is finally accepted by the customer.
• Confusion: Customer can confuse between the actual product and prototype.

Spiral Model

 

The spiral model is a software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. The spiral model is also known as meta-model since it encompasses all other life cycle models.

It 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 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 diagram below shows different phases of the Spiral Model:

Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions of these four quadrants are discussed below-

1. Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution is identified and the risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started.

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.

Prototyping Model also support 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 Prototyping Model. In each phase of the Spiral Model, the features of the product dated and analyzed and the risks at that point of 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 as 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 step-wise approach of the Classical Waterfall Model.It  uses the approach of 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: Spiral Model is the best model to follow for development 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 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 dependable on Risk Analysis: The successful completion of the project is very much dependent on Risk Analysis. Without highly experienced expertise, it is not possible 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 : Lecture 5

Department : MCA

Semester     : IV

Subject        : Principles of Software Engineering                                             

Paper           : 21

Faculty        : Avinash Kumar

Syllabus covered in  this blog:

V Model

V Model

The software development life cycle has various models which follow a different approach to culminate a prototype to a successful product. In the previous chapter, we have learned about the Waterfall model - the V-model is an extension of the waterfall model. Usually, this model is pronounced as Vee model. This model is quite different from the Waterfall model because, in every phase of it, there is a related testing stage associated. In this chapter, you will learn about the V-Model and its approach to software development.

The V-model of SDLC carries out its execution in a sequential manner. The structure it follows takes the shape of the letter V. This model is also popularly termed as a Verification and Validation model. Here, each phase has to be finished before beginning the next phase. A sequential design progression is followed like that of the waterfall model.

Design of Model

In parallel to the software development phase, a corresponding series of test phase also runs in this model. Each stage comprises a specific type of testing done, and once that testing is passed, only then the next phase starts.

• Verification: In the concept of verification in the V-Model, static analysis technique is carried out without executing the code. This evaluation procedure is carried out at the time of development to check whether specific requirements will meet or not.
• Validation: This concept of V-Model comprises of dynamic analysis practice (both functional as well as non-functional), and testing is done by code execution. The validation of a product is done once the development is complete for determining if the software meets up the customer hope needs.

So both verification and validation are combined and work in parallel to make the 

V-Model fully functional. 

Design Phase

• Requirement Analysis: In this stage of SDLC, a detailed conversation with the customer is made to understand their requirements as well as anticipation. Requirement gathering is another name of this phase.
• System Design or High-level Design: In this phase of SDLC, the system is designed with the entire hardware & the setup is constructed for product development.
• Architectural Design: The breakdown of system design to a more detailed version, i.e., into modules which creates different functionalities. Transferring of data and connection between internal and external modules (i.e., the outside world) is evidently identified.
• Low-level design or Module Design: This particular phase breaks down the entire product development into tiny modules where each intended module is specified. So it is also termed as Low-Level Design (LLD).

Testing Phase

• Unit Testing: During the development of module design, unit testing is carried out. This plan is executed for eliminating bugs that are found in code at the development of your software. 
• Integration Testing: Once the unit testing is done, the integration testing is carried out where the integration of modules in the system is hardened. This testing is done in the architecture design phase. 
• System Testing: This ultimate test is done when the entire product is completed in conjunction with the functionality, internal dependency requirement and merging of different modules into a single unit. 
• User Acceptance Testing: This type of testing is carried out in front of the user or in a user environment where the product will ultimately set up. The UAT particularly test whether the product is capable enough to launch in the market or ready to work in the real world.

Principles of V-Model:

• Large to Small: In V-Model, testing is done in a hierarchical perspective, For example, requirements identified by the project team, create High-Level Design, and Detailed Design phases of the project. As each of these phases is completed the requirements, they are defining become more and more refined and detailed.
• Data/Process Integrity: This principle states that the successful design of any project requires the incorporation and cohesion of both data and processes. Process elements must be identified at each and every requirements.
• Scalability: This principle states that the V-Model concept has the flexibility to accommodate any IT project irrespective of its size, complexity or duration.
• Cross Referencing: Direct correlation between requirements and corresponding testing activity is known as cross-referencing.
• Tangible Documentation: This principle states that every project needs to create a document. This documentation is required and applied by both the project development team and the support team. Documentation is used to maintaining the application once it is available in a production environment.

Advantages:

• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle thereby enhancing the probability of building an error-free and good quality product.
• It enables project management to track progress accurately.

Disadvantages:

• High risk and uncertainty.
• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and contains high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.

Data Structures through C++ : Video Lecture 2

Data Structures through C++(Asymptotic notations)

Data Structures Video Lecture 1

Department: MCA
Semester    : II

Subject       : Data Structures through C++

Paper          : CCMCA 203

Faculty       : Avinash Kumar

Data Structures through C++ : Question Bank

Department: MCA
Semester    : II

Subject       : Data Structures through C++

Paper          : CCMCA 203

Faculty       : Avinash Kumar

Students are advised to prepare answers to the questions considering each of the questions as a long answer question. Provide appropriate code segment wherever needed.

1. What Does Abstract Data Type Mean?
2. What is a Data Structure?
3. What Are The Goals Of Data Structure?
4. List Out the Areas in Which Data Structures Are Applied Extensively?
5. What are linear and non linear data Structures?
6. What are the various operations that can be performed on different Data Structures?
7. What Is Sequential Search?
8. What Is Dangling Pointer And How To Avoid It?
9. How is an Array different from Linked List?
10. What Do You Mean By Recursive Definition?
11. What is Stack and where it can be used?
12. Convert the Expression ((a + B) * C - (d - E) ^ (f + G)) To Equivalent Prefix and Postfix Notations?
13. What Do You Mean By Overflow And Underflow?
14. What Is The Difference Between A Stack And An Array?
15. What Is A Queue?
16. What Is A Priority Queue?
17. What is a Queue, how it is different from stack and how is it implemented?
18. What are Infix, prefix, Postfix notations?
19. What is a Linked List and what are its types?
20. Define Circular List?
21. What Are The Disadvantages Of Circular List?
22. What Are the Advantages of Linked List over Array (static Data Structure)?
23. What Do You Mean By Garbage Collection?
24. Which data structures are used for BFS and DFS of a graph?
25. Can doubly linked be implemented using a single pointer variable in every node?
26. Which Data Structure Should be used for implementing LRU cache?
27. How to check if a given Binary Tree is BST or not?
28. List out Few of the Application of Tree Data-structure?
29. What Is The Type Of The Algorithm Used In Solving The 8 Queens Problem?
30. In RDBMS, What Is The Efficient Data Structure Used In The Internal Storage Representation?
31. What Is A Spanning Tree?
32. Does The Minimal Spanning Tree Of A Graph Give The Shortest Distance Between Any 2 Specified Nodes?
33. What Is The Difference Between Null And Void Pointers?
34. What is algorithm?
35. What are the criteria of algorithm analysis?
36. What is asymptotic analysis of an algorithm?
37. What are asymptotic notations?
38. Briefly explain the approaches to develop algorithms.
39. Give some examples greedy algorithms.
40. What are some examples of divide and conquer algorithms?
41. What are some examples of dynamic programming algorithms?
42. What operations can be performed on stacks?
43. What operations can be performed on Queues?
44. What is binary search?
45. What is bubble sort and how bubble sort works?
46. What is selection sort?
47. What is merge sort and how it works?
48. Explain 'insertion sort'?
49. How quick sort works?
50. What is a graph?
51. How depth first traversal works?
52. How breadth first traversal works?
53. What is a tree?
54. What is a binary tree?
55. What is a binary search tree?
56. What is tree traversal?
57. What is an AVL Tree?
58. How many spanning trees can a graph has?
59. How Kruskal's algorithm works?
60. How Prim's algorithm finds spanning tree?
61. What is a minimum spanning tree (MST)?
62. What is a heap in data structure?
63. What is hashing?
64. Explain Tower of Hanoi concept.
65. What do you mean by Huffman Code?
66. What are Multiway Trees? Explain its various types.

Waterfall Model: Lecture 4

Department : MCA

Semester     : IV

Subject        : Principles of Software Engineering                                             

Paper           : 21

Faculty        : Avinash Kumar

Syllabus covered in  this blog:

Waterfall Model

Linear/Sequential Model (Waterfall Model)

Classical waterfall model is the basic software development life cycle model. It is very simple but idealistic. Earlier this model was very popular but nowadays it is not used. But it is very important because all the other software development life cycle models are based on the classical waterfall model.

Classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can be started after completion of the previous phase. That is the output of one phase will be the input to the next phase. Thus the development process can be considered as a sequential flow in the waterfall. Here the phases do not overlap with each other.

• Feasibility Study:

   The main goal of this phase is to determine whether it would be financially and technically feasible to develop the software. The feasibility study involves understanding the problem and then determines the various possible strategies to solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks, the best solution is chosen and all the other phases are carried out as per this solution strategy.

• Requirements analysis and specification:

    The aim of the requirement analysis and specification phase is to understand the exact requirements of the customer and document them properly. This phase consists of two different activities.

•         Requirement gathering and analysis: 

             Firstly all the requirements regarding the software are gathered from the customer and then the gathered requirements are analyzed. The goal of the analysis part is to remove incompleteness (an incomplete requirement is one in which some parts of the actual requirements have been omitted) and inconsistencies (inconsistent requirement is one in which some part of the requirement contradicts with some other part).

•         Requirement specification:

          These analyzed requirements are documented in a software requirement specification (SRS) document. SRS document serves as a contract between development team and customers. Any future dispute between the customers and the developers can be settled by examining the SRS document.

• Design:

    The aim of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language.

•   Coding and Unit testing:

In coding phase software design is translated into source code using any suitable programming language. Thus each designed module is coded. The aim of the unit testing phase is to check whether each module is working properly or not.

• Integration and System testing:

Integration of different modules are undertaken soon after they have been coded and unit tested. Integration of various modules is carried out incrementally over a number of steps. During each integration step, previously planned modules are added to the partially integrated system and the resultant system is tested. Finally, after all the modules have been successfully integrated and tested, the full working system is obtained and system testing is carried out on this. System testing consists of three different kinds of testing activities:

o   Alpha testing:

Alpha testing is the system testing performed by the development team.

o   Beta testing:

Beta testing is the system testing performed by a friendly set of customers

o   Acceptance testing:

After the software has been delivered, the customer performed the acceptance testing to determine whether to accept the delivered software or to reject it.

•    Maintenance:

Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is the 60% of the total effort spent to develop a full software. There are basically three types of maintenance:

o   Corrective Maintenance:

o   This type of maintenance is carried out to correct errors that were not discovered during the product development phase.

o   Perfective Maintenance:

o   This type of maintenance is carried out to enhance the functionalities of the system based on the customer’s request.

o   Adaptive Maintenance:

Adaptive maintenance is usually required for porting the software to work in a new environment such as work on a new computer platform or with a new operating system.

Advantages of Classical Waterfall Model

Classical waterfall model is an idealistic model for software development. It is very simple, so it can be considered as the basis for other software development life cycle models. Below are some of the major advantages of this SDLC model:

• This model is very simple and is easy to understand.
• Phases in this model are processed one at a time.
• Each stage in the model is clearly defined.
• This model has very clear and well understood milestones.
• Process, actions and results are very well documented.
• Reinforces good habits like define-before- design, design-before-code.
• This model works well for smaller projects and projects where requirements are well understood.

Drawbacks of Classical Waterfall Model

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 classical waterfall model evolution of a software from one phase to another phase is like a waterfall. It assumes that no error is ever committed by developers during any phases. 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 customers’ 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 new phase can start only after the completion of the previous phase. But in real projects, this can’t be maintained. To increase the efficiency and reduce the cost, phases may overlap.

Iterative Waterfall Model

In a practical software development project, the classical waterfall model is hard to use. So, Iterative waterfall model can be thought of as incorporating the necessary changes to the classical waterfall model to make it usable in practical software development projects.

It is almost same as the classical waterfall model except some changes are made to increase the efficiency of the software development. The iterative waterfall model provides feedback paths from every phase to its preceding phases, which is the main difference from the classical waterfall model. 

When errors are detected at some later phase, these feedback paths allow correcting errors committed by programmers during some phase. The feedback paths allow the phase to be reworked in which errors are committed and these changes are reflected in the later phases.

There is no feedback path to the stage – feasibility study, because once a project has been taken, does not give up the project easily. It is good to detect errors in the same phase in which they are committed. It reduces the effort and time required to correct the errors.

Phase Containment of Errors:

The principle of detecting errors as close to their points of commitment as possible is known as Phase containment of errors.

Advantages of Iterative Waterfall Model

Feedback Path:

In the classical waterfall model, there are no feedback paths, so there is no mechanism for error correction. But in iterative waterfall model feedback path from one phase to its preceding phase allows correcting the errors that are committed and these changes are reflected in the later phases.

Simple:

Iterative waterfall model is very simple to understand and use. That’s why it is one of the most widely used software development models.

Drawbacks of Iterative Waterfall Model

Difficult to incorporate change requests:

The major drawback of the iterative waterfall model is that all the requirements must be clearly stated before starting of the development phase. Customer may change requirements after some time but the iterative waterfall model does not leave any scope to incorporate change requests that are made after development phase starts.

Incremental delivery not supported:

In the iterative waterfall model, the full software is completely developed and tested before delivery to the customer. There is no scope for any intermediate delivery. So, customers have to wait long for getting the software.

Overlapping of phases not supported:

Iterative waterfall model assumes that one phase can start after completion of the previous phase, But in real projects, phases may overlap to reduce the effort and time needed to complete the project.

Risk handling not supported:

Projects may suffer from various types of risks. But, Iterative waterfall model has no mechanism for risk handling.

Limited customer interactions:

Customer interaction occurs at the start of the project at the time of requirement gathering and at project completion at the time of software delivery. These fewer interactions with the customers may lead to many problems as the finally developed software may differ from the customers’ actual requirements.