Unit – 1
Software Process Models
Software Products are software systems that are given to customers along with documentation that explains how to install and use them. In some circumstances, software goods are given to customers as part of system products, which include both hardware and software. The software process aids in the creation of software products. The software development process is the method by which we create software.
Types of software products
There are two types of software available:
Generic products are stand-alone systems developed by a manufacturing unit and offered on the open market to anyone who can afford them.
2. Customized products:
The systems that are commissioned by a specific customer are known as customized products. For that customer, a contractor creates the software.
Essential characteristics of Well-Engineered Software Product:
The following are fundamental qualities of a well-engineered software product:
Efficiency
System resources such as memory and processor cycles should not be wasted by the software.
Maintainability
The software should be able to evolve to suit the needs of clients as they change.
Dependability
In the event of a system breakdown, the software's adaptability should not result in any bodily or financial harm. It encompasses a number of qualities such as dependability, security, and safety.
In time
Software must be developed in a timely manner.
Within Budget
The software development expenditures should not exceed the budgeted limit.
Functionality
The software system should have proper functioning, that is, it should be able to accomplish all of the functions that it is designed to.
Adaptability
The software system should be able to adapt to new requirements in a reasonable amount of time.
Key takeaway
● Size and cost: Software's sophistication and expectations are increasing on a daily basis. Software is becoming more costly and complex.
● Quality: The quality of software products must be high.
● Delayed Delivery: The development of software takes longer than anticipated, resulting in increased costs.
● Many software programs collapsed during the late 1960s.
● A lot of apps went over budget. The result was faulty software that was costly to maintain.
● Maintaining larger software was difficult and costly.
● Many pieces of software are unable to meet the ever-increasing demands of customers.
● As the hardware capability of a software project grew, the complexity of the project increased as well.
● When opposed to the ability to produce new applications, demand for new software grew faster.
Most of the above problems result in a 'Software Crisis.'
The Solution
The problem was solved by turning a disorganized coding effort into a software engineering discipline. These innovation models aided businesses in streamlining processes and delivering applications that met consumer needs.
● Software engineering principles were widely used in the late 1970s.
● In the 1980s, the software engineering process was automated, and CASE (Computer-Aided Software Engineering) grew in popularity.
● In the 1990s, there was a greater focus on the 'management' aspects of programs, such as ISO 9001 quality standards and processes.
Abstraction
It means the process of constructing a simpler version of an issue by omitting details. Modeling is a term used to describe the process of creating an abstraction.
It is the process of simplifying an issue by focusing on only one component of it while ignoring all others. When applying the principle of abstraction to a complex situation, we pay attention to only one or two specific parts of the problem while ignoring the rest.
A model of a problem is created whenever some specifics of a problem are omitted in order to create an abstraction. In everyday life, we routinely apply the idea of abstraction to comprehend an issue or appraise a situation.
Fig 1: abstraction and decomposition
Decomposition
It's yet another crucial principle in a software engineer's toolkit for dealing with problem complexity. Several software engineering methodologies make extensive use of this notion to limit the exponential development of perceived problem complexity. The divide and conquer principle is a popular name for the decomposition concept.
The decomposition concept encourages breaking the problem down into many small, self-contained sections. The little sections are then pulled apart and solved one at a time. The goal is that each small component will be simple to absorb and comprehend, as well as to solve. When all of the elements of the problem are solved, the whole problem is solved.
Key takeaway
Software development can be done in a variety of ways. However, each one usually involves activities that can be grouped into the following categories:
● Domain modelling: Understanding the business processes and procedures that may be used to introduce a system. This is usually the first step before deciding to construct a software system.
● Requirements: (Requirement’s engineering is another name for it.) Requirement’s elicitation, which involves identifying the problem, and needs analysis, which involves categorizing, prioritizing, and modeling requirements. This explains what the system is supposed to perform.
● Design: Choosing a method for resolving the issue.
● Implementation: Taking action based on the decisions made during the design stage.
● Testing: You should test what you've done to see if you've solved the problem.
Different techniques may split or label the above actions differently. The Unified Process is a unique technique (UP).
The method is defined as a set of tasks, activities and tasks performed when a work product is to be produced. The acts and tasks of each of these activities are based on a structure or model that determines their relationship with the process and with each other.
A process model (also termed as software life cycle model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents
all the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken.
The software process is depicted schematically, with a collection of software engineering activities populating each framework activity.
A task set that defines the work tasks to be completed is defined by each software engineering activity. The working products to be made, the points of quality assurance that will be needed, and the milestones to be used to demonstrate progress.
● It is a simplest model, which states that the phases are organized in a linear order.
● The model was originally proposed by Royce.
● The various phases in this model are
● Feasibility Study – The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system as well as various constraints on the behavior of the system.
● Requirement Analysis – The aim of the requirement analysis is to understand the exact requirements of the customer and to document them properly. The requirement analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. During this activity, the user requirements are systematically organized into a software requirement specification (SRS) document. The important components of this document are the functional requirements, the nonfunctional requirements, and the goals of implementation. The SRS document is written in end-user terminology. This makes the SRS document understandable by the customer. After all, it is important that the SRS document be reviewed and approved by the customer.
● Design – This phase is concerned with
● Identifying software components like functions, data streams and data stores.
● Specifying software structure.
● Maintaining a record of design decisions and providing.
● There are two categories of Design:
● Architectural Design – It involves
● Identifying the software components.
● Decoupling and decomposing the software component into modules and conceptual data structures.
● Specifying the interconnection between the various blueprints for the implementation phase
● Detailed Design – It is concerned with details of the implementation procedures to process the algorithms, data structures and interaction between the modules and data structures. The various activities that this phase includes are
● Adaptation of existing code.
● Modification of existing algorithms.
● Design of data representation and
● Packaging of the software product.
This process is highly influenced by the programming language under which the implementation would be carried out. This stage is different from implementation
● Implementation – It involves the translation of the design specifications into source code. It also involves activities like debugging, documentation and unit testing of the source code. In this stage various styles of programming can be followed like built-in and user defined data types, secure type checking, flexible scope rules, exception handling, concurrency control etc.
● Testing – It involves two kinds of activities
● Integration Testing – It involves testing of integrating various modules and testing their overall performance due to their integration.
● Acceptance Testing – It involves planning and execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirements stated in the requirements document.
● Maintenance – In this phase the activities include
● Corrective Maintenance – Correcting errors that were not discovered during the product development phase.
● Perfective Maintenance – Improving the implementation of the system, and enhancing the functionalities of the system according to customer’s requirements.
● Adaptive Maintenance – Adaptation of software to new processing environments.
Fig 2: Classical waterfall model
Advantages of Waterfall model
● All phases are clearly defined.
● One of the most systematic methods for software development.
● Being older, this is one of the time-tested models.
● It is simple and easy to use.
Disadvantages of Waterfall Model
● Real Projects rarely follow sequential models.
● It is often difficult for the customer to state all requirements explicitly.
● Poor model for complex and object-oriented projects.
● Poor model for long and ongoing projects.
● High amount of risk and uncertainty.
● Poor model where requirements are at a moderate to high risk of changing.
● This model is suited to automate the existing manual system for which all requirements are known before the design starts. But for the new system, having such unchanging requirements is not possible.
Key takeaway:
The classical waterfall methodology is difficult to apply in a real-world software development project. As a result, the Iterative waterfall model can be regarded as adding the essential improvements to the traditional waterfall model in order to make it viable in real-world software development projects. It's basically identical to the traditional waterfall approach, with a few tweaks to improve software development productivity.
The fundamental distinction between the iterative waterfall model and the classical waterfall model is that the iterative waterfall model provides feedback pathways from each step to the phases before it.
Fig 3: iterative waterfall model
When faults are discovered at a later stage, these feedback pathways allow programmers to remedy faults made earlier in the process. The feedback channels allow the phase in which errors are committed to be modified, and the modifications are reflected in subsequent phases. However, there is no feedback path to the stage – feasibility study, because once a project is started, it is difficult to abandon it.
It is preferable to discover errors while they are still being committed. It cuts down on the time and effort required to fix errors.
Phase Containment of Errors: Phase containment of errors is the notion of discovering errors as close to their places of commitment as possible.
Advantages
● Feedback path
● Simple
Disadvantages
● Difficult to incorporate change requests
● Incremental delivery not supported
● Overlapping of phases not supported
● Risk handling not supported
● Limited customer interactions
Key takeaway
Fig 4: Prototyping model of software development
● Often, a customer defines a set of general objectives for software, but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these and many other situations, a prototyping paradigm may offer the best approach.
● The various phases of this model are
● Listen to Customer: - This is the starting step, where the developer and customer together
● Define the overall objectives for the software,
● Identify the known requirements and
● The analyst then outlines those factors and requirements that are not visible normally but are mandatory from a development point of view.
● Build prototype: - After the identification of the problem a quick design is done which will cause the software to show the output that the customer wants. This quick design leads to the development of a prototype (a temporary working model).
● Customer test drives the prototype: - The customer runs and checks the prototype for its perfection. The prototype is evaluated by the customer and further improvements are made to the prototype unless the customer is satisfied.
● All the stages are repeated until the customer gets satisfied. When the final prototype is fully accepted by the customer then final development processes like proper coding for attaining maintainability, proper documentation, testing for robustness etc. are carried out. And finally, the software is delivered to the customer.
Advantages
● It serves as the mechanism for identifying the requirements.
● The developer uses the existing program fragment means it helps to generate the software quickly.
● Continuous developer – Consumer communication is available.
Disadvantages
● Customer considers the prototype as an original working version of the software.
● Developer makes implementation compromises in order to get the prototype working quickly.
● This model is time consuming.
Key takeaway
SDLC Evolutionary model builds the required product in several successive versions and hence is also known as successive version model or incremental model
● In this model the requirement is broken down into different functional units
● These functional units are known as modules
● The functionality improvements are done in these modules until the desired system is realized
● Each successive version is capable of performing more functions than the previous versions
Release of different evolutionary versions in SDLC:
Fig 5: Evolutionary development of a software product
● Each of the version will be released with some new functionalities added to the older one
● Here B will have more functionality than A, but will exhibit less capability than C
● As the system is viewed to be developed in incremental way so it is also termed as incremental model of development
Advantages:
● In this model the user gets a chance to experiment partially developed system
● It reduces the error because the core modules get tested thoroughly
Disadvantages:
● Sometimes it becomes hard to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented and delivered.
Fig 6: Evolutionary model of software development
Types of projects for which it is suitable:
● The evolutionary model is basically useful for very large products.
● Rather than waiting for the full product, the customer prefers to receive the product in increments so that he can start using them.
Key takeaway:
● Evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.
● It provides the potential for rapid development of incremental versions of the software.
● Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.
● A spiral model is divided into a number of framework activities, also called task regions.
● There are six task regions.
● Customer communication—tasks required to establish effective communication between developer and customer.
● Planning—tasks required to define resources, timelines, and other project related information.
● Risk analysis—tasks required to assess both technical and management risks.
● Engineering—tasks required to build one or more representations of the application.
● Construction and release—tasks required to construct, test, install, and provide user support (e.g., documentation and training).
● Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Fig 7: Spiral model of software development
Advantages:
● It is a realistic approach for development of large-scale systems.
● High amount of risk analysis.
● Good for large and mission-critical projects.
● Software is produced early in the software life cycle.
Disadvantages:
● It is not widely used.
● It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable.
● It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.
● Can be a costly model to use.
● Risk analysis requires highly specific expertise.
● Project’s success is highly dependent on the risk analysis phase.
● Doesn’t work well for smaller projects.
Key takeaway
The Rapid Application Development (or RAD) paradigm is focused on prototyping and an iterative process with little (or no) planning ahead of time. In general, taking a RAD approach to software development implies focusing less on planning and more on development and creating a prototype. In contrast to the waterfall paradigm, which emphasizes rigorous specification and preparation, the RAD approach focuses on continuously developing needs as the development develops.
RAD places a strong emphasis on prototyping as an alternative to design requirements. This indicates that RAD performs well in situations where the user interface is more important than non-GUI programs. Agile technique and spiral model are part of the RAD model.
Model Design
The steps of the rapid application development (RAD) model are as follows:
Fig 8: RAD model
Advantages
● Adapting to changing demand is possible.
● It is possible to track progress.
● With the use of sophisticated RAD tools, iteration time can be cut in half.
● In a short period of time, productivity may be achieved with fewer workers.
● Development time is cut in half.
● Component reusability is improved.
● Initial reviews are conducted quickly.
● Encourages comments from customers.
● Many integration challenges can be avoided by integrating from the start.
Disadvantages
● Dependency on technically strong team members for identifying business requirements.
● Only systems that can be modularized can be built using RAD.
● Requires highly skilled developers/designers.
● High dependency on Modelling skills.
● Inapplicable to cheaper projects as cost of Modelling and automated code generation is very high.
● Management complexity is more.
● Suitable for systems that are component based and scalable.
● Requires user involvement throughout the life cycle.
● Suitable for projects requiring shorter development times.
Key takeaway
On these tasks and coding, Intense Programming builds. With many tight feedback loops through efficient implementation, testing and continuous refactoring, it is the comprehensive (not the only) design operation.
Extreme Programming is based on the values below:
● Communication
● Simplicity
● Feedback
● Courage
● Respect
XP is a software development that is lightweight, effective, low-risk, scalable, predictable, science and fun.
In the face of unclear and evolving requirements, eXtreme Programming (XP) was conceived and developed to meet the unique needs of software development by small teams.
One of the methodologies of Agile software development is Extreme Programming. It offers beliefs and ideals to guide the actions of the team. It is predicted that the team will self-organize. Extreme programming offers particular core activities in which
● Each activity is easy and complete in itself.
● More complex and changing behaviour is created by a combination of techniques.
Extreme Programming involves −
● Prior to programming, writing unit tests and keeping all of the tests running at all times. Unit testing is automated and faults are eliminated early, thus lowering costs.
● Just enough to code the features at hand and redesign when necessary, beginning with a basic design.
● Pair programming (called pair programming), with two programmers on a single computer, using the keyboard in turns. When one of them is on the keyboard, the other continuously reviews and gives suggestions.
● Several times a day, implementing and checking the entire system.
● Rapidly bringing a minimal working system into development and updating it whenever appropriate.
● Holding the client active and receiving constant input all the time.
As the programme progresses with the evolving demands, iterating enables the accommodating changes.
Fig 9: extreme programming
Scrum
Scrum is a lightweight agile method system mainly used for software development management. Hey, scrum is
● Lightweight since it has few components that are recommended
● Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
● Three meetings: Sprint Planning, Daily Scrum, Retrospective
● Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
● Agile as it maximises responsiveness to evolving needs of customers
● A system structure because it is not a method, but a set of methods and principles from which a process can be constructed.
Scrum is a process system that, since the early 1990s, has been used to handle work on complex goods. Scrum is not a procedure, methodology, or conclusive process. Instead, it is a structure within which different processes and techniques can be employed. Scrum makes clear the relative effectiveness of the product management and job strategies such that the product, the staff, and the working atmosphere can be continually enhanced.
Scrum Teams and their related tasks, events, objects, and rules consist of the Scrum system. Each component serves a particular role within the system and is important to the success and use of Scrum.
Scrum's rules tie the functions, activities, and objects together, governing the relationships and interaction between them.
Benefits of scrum:
From a software development process, various stakeholders want distinct things.
● Developers want code, not documents, to be written.
● Quality Assurance engineers want to build research plans that guarantee the quality of the product and provide a high-quality code to test.
● Project managers want a process that is simple to schedule, implement, and control.
● Product Managers want features that are easily implemented, with no bugs.
Key takeaway
● XP is a software development that is lightweight, effective, low-risk, scalable, predictable, science and fun.
● One of the methodologies of Agile software development is Extreme Programming.
● It offers beliefs and ideals to guide the actions of the team.
● Scrum is not a procedure, methodology, or conclusive process.
● Scrum Teams and their related tasks, events, objects, and rules consist of the Scrum system.
References:
