Unit 1
Introduction to Software Engineering and Software Process Models
Software engineering works with a variety of software production methods. It accompanies software product development using well-defined scientific principles, methods, and processes. The result of software engineering is an efficient and reliable software product.
The term software engineering is coined with the addition of ‘software + engineering’. Software is more than just program code. The program is a usable code, which serves a specific calculation purpose. Software is considered a collection of effective editing code, compatible libraries, and texts. Software, when required for a specific purpose, is called product software.
According to IEEE: Software Engineering is the systematic approach to the development, operation, maintenance, and retirement of the software.
According to Bohem: “Software Engineering is the application of science and mathematics by which capabilities of computer equipment are made useful to man through computer programs, procedures, and related documentation.”
Software Engineering is based on the following disciplines:
● Computer Science
● Management Science
● Economics
● Communication Skills
● An engineering approach to problem-solving
Software Engineering is a branch of engineering that uses well-defined scientific principles, techniques, and procedures to develop software products. A successful and reliable software product is the result of software engineering.
Key takeaway :
- Software is more than mere code for a program.
- On the other hand, engineering is all about product creation, using well-defined scientific concepts and methods.
- Software engineering is a branch of engineering that uses well-defined scientific concepts, methods, and procedures to create software products.
For systems engineering (SE) of software-intensive systems, the essence of the software medium has many implications. It is distinguished from other types of engineering objects by four software properties, taken together.
Such four properties are the following:
Brooks states:
“Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.”
Complexity:
The complexity of software emerges from a large number of specific components in a software system that communicate with each other.
The sections are special because they are encapsulated instead of being repeated as functions, subroutines, or objects, and invoked as necessary. There are many different types of interactions with software modules, including serial and concurrent invocations, state transformations, data couplings, and database and external device interfaces.
To illustrate the various static structures, dynamic couplings, and modes of interaction that occur in computer software, the depiction of a software object also involve many different design representations. Complexity within the components and in the relations between components requires significant design rigour and regression testing for modifications. For modules that are embedded, distributed, and data-based, the software provides functionality.
As well as complicated algorithms and heuristics, the software can implement simple control loops.
Complexity can cover defects that cannot be easily detected, requiring considerable additional and unplanned rework.
Changeability:
Software coordinates the operation of physical components and, in software-intensive systems, provides much of the features. Because the software in a software-intensive system is the most malleable (easily changed) element, it is the most frequently changed element.
During the late stages of a development project and system maintenance, this is particularly true. This does not mean, however, that software is easy to modify. Complexity and the need for conformity will make it an incredibly difficult task to update software.
In other parts of the system, modifying one aspect of a software system often results in undesired side effects, requiring further adjustments before the software can work at maximum performance.
Conformity:
Unlike a physical product, the software has no fundamental natural rules that it must adhere to, such as the laws of motion of Newton. However, in the representation of any of its components, in the interfaces to other internal parts, and in the connections to the world in which it works, the program must comply with exacting requirements.
A compiler may detect a missing semicolon or other syntactic error, but it may be difficult to detect a defect in the program logic or a timing error until it is encountered during operation.
Lack of conformity will trigger problems when it is not feasible to reuse an existing software feature as designed because it does not meet the needs of the product under development. This needs (usually) an unplanned allocation of resources which can delay the completion of the project.
Invisibility:
Software, since it has no physical properties, is said to be invisible. Although the results of software execution on a digital device are measurable, it is not possible to see, taste, smell, touch, or hear the software itself. Software is an intangible entity because it is unable to be sensed directly by our five human senses.
Job products such as descriptions of specifications, design documents, source code, and object code are software representations, but they are not software.
Software remains in the magnetization and current flow at the most elementary stage in an enormous number of electronic elements inside a digital system. Since the software has no physical presence, to image the essentially intangible object, software engineers must use various representations at different levels of abstraction.
Uniqueness:
The uniqueness of software is another point about the existence of software that Brooks alludes to but does not specifically call out. For the following reasons, software and software projects are unique:
● There are no physical properties for software;
● The product of intellect-intensive teamwork is software;
● Software developers' productivity varies more broadly than other engineering disciplines' productivity.
● Software project risk management is primarily process-oriented;
● Software alone, as it is often a part of a larger scheme, is useless, and
● The most frequently updated aspect of software-intensive systems is software.
Key takeaway :
- software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
- The complexity of software emerges from a large number of specific components in a software system that communicate with each other.
- Because the software in a software-intensive system is the most easily changed element.
Software is a program that when executed provides desired functions, features, and performance.
A data structure that allows information to be manipulated correctly by the software.
Documentation that explains the program's process and use.
Features of software:
● Functionality: Refers to the degree of performance of the software against its intended purpose.
● Reliability: Refers to the ability of software to perform a required function under given conditions for a specified period.
● Usability: Refers to the degree to which software is easy to use.
● Efficiency: Refers to the ability of software to use system resources most effectively and efficiently. • Maintainability: Refers to the ease with which a software system can be modified to add capabilities, improve system performance, or correct errors.
● Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with a minimum) changes Robustness: is the ability of software to handle unexpected errors and faults with ease.
● Integrity: integrity in software is the better quality of the software’s source code.
It contains a set of ideas, principles, processes, and tools that are called upon daily by a software engineer.
Equipping managers to handle software projects and software engineers to construct computer programs offers the necessary strategies and management to do the job.
● Who has a stake in the problem's solution?
● What unknowns are there? And what is needed (data, function, behaviour) to solve the problem properly?
● Can the problem be graphically represented? Can a model be developed for analysis?
● Is it possible to compartmentalize the problem? It is possible to portray smaller topics that might be simpler to learn.
B. Plan a solution (planning, modeling, and software design)
● Have you seen issues close to this before?
● Has a similar question been resolved? If not, are the solution's components reusable?
● Is it possible to identify sub-issues and are solutions available for the sub-issues?
C. Carry out the plan (construction, code generation)
● Does the solution comply with the plan? Can the source code be traced back to the design?
● Is each part of the solution accurate? Were the layout and code tested, or better?
D. Examine the results for accuracy (testing and quality assurance)
● Can each part of the solution be tested? Has a sound plan for testing been implemented?
● Does the solution produce a result that corresponds to the data, function, and behaviour that are required?
● Was the program validated against the demands of all stakeholders?
It is important to go through a series of predictable steps as you work to create a product or system - a road map that helps you produce a timely, high-quality result.
A " software process" is called the road map that you follow.
Technical definition:
The software process is a structure for the operations, activities, and tasks needed to create high-quality software.
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 a 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.
A generic system of process work for software engineering framework tasks -
Five application activities for communication, planning, modeling, construction, and deployment describe a common process framework for software engineering. Besides, a range of umbrella practices is implemented throughout the process: project monitoring and tracking, risk management, quality assurance, configuration management, technical reviews, and others. (called process flow)
Fig 1: Generic model
While I have defined five system activities and provided a fundamental description of each software team, before it could properly conduct any of these activities as part of the software process, it would need significantly more details.
You are then faced with a key question: what activities are suitable for a system operation, considering the nature of the problem to be solved, the features of the people doing the job, and the stakeholders funding the project?
Fig. 2: process flow
The communication process could include nothing more than a phone call with the appropriate stakeholder for a small software project requested by one person (at a remote place) with clear, straightforward specifications.
Therefore, phone contact is the only action required, and the job tasks (the work set) that this action entails are:
● Make communication via telephone with the stakeholder.
● Evaluate and take notes on specifications.
● Organize notes in a short statement of specifications in writing.
● For evaluation and acceptance via E-mail to stakeholders.
If the project with several stakeholders, each with a different set of often contradictory criteria, was considerably more complex, the contact operation may have six separate actions: initiation, elicitation, elaboration, negotiation, pacification, and validation. There will be several working activities and a range of different work items for each of these software engineering acts.
The actual work to be done to achieve the goals of a software engineering operation is specified by a task set. For example, elicitation is an essential action in software engineering that occurs during the activity of communication.
The purpose of the requirement set is to understand what the software that is to be developed needs from different stakeholders.
The task set for the collection of requirements could look like this for a small, relatively simple project:
A different task set will be needed for a larger, more complex software project. The following job assignment must include it
Both of these task sets accomplish " requirements gathering" but in their depth and formality, they are very different. The software team selects the set of tasks that will allow it to achieve each action's goal and yet retain quality and agility.
Products of the application of abstraction to recurrent structures and processes Components of processes.
Build means to develop methodologies by creating a means to develop methodologies by writing suitable pattern cases.
It represents the state of practice and is focused on well-established, distilled principles.
Coplien defined process patterns as “the patterns of activity within an organization (and hence within its project)”. The first recorded reference was made to the term "Process Pattern" by Coplien in 1994 in his landmark article.
Nearly all of his trends are fairly fine-grained techniques for improved operational and management processes by introducing g gp gp.
It May does not constitute a detailed, coherent whole to define a Process development software development process.
The following template for defining a process pattern has been proposed by Ambler:
Patterns name: A significant name is given to the pattern which describes its functions within the software method (e.g., customer-communication).
Intent: The goal of the pattern is briefly defined. The aim of customer contact, for instance, is "to establish a collaborative relationship with the customer to define the scope of the project, business requirements, and other limitations of projects"
Types: The form of the pattern is defined. Three forms are proposed by Ambler:
Initial Context. The conditions are defined in which the pattern applies.
We ask -
(1) what activities have already been generated by the organizational team?
(2) before the initiation of the pattern, what is the entry state for the process?
(3) the complexity of the project, basic business criteria, and limitations of the project are known.
The evaluation of the process is to ensure that it meets a set of fundamental process requirements that have been demonstrated to be necessary for good software engineering. During the past few decades, a variety of different approaches to software process evaluation have been proposed:
Standard CMMI Assessment Method for Process Improvement (SCAMPI) – It offers a five-step model of process evaluation that involves initiating, diagnosing, creating, acting, and learning. As the basis for evaluation, the SCAMPI techniques use the SEI CMMI.
II. ISO9001: 2000 for Software is a general standard for any company that wishes to enhance the overall quality of the products, systems, or services it offers. The standard is, therefore, specifically applicable to software organizations and businesses.
The Capability Maturity Model Integration (CMMI)
A comprehensive process meta-model has been developed by the Software Engineering Institute (SEI), which is focused on a set of system and software engineering skills that should be present as organizations achieve various levels of process competence and maturity.
The SEI contends that an enterprise should develop a process model that confirms the Capability Maturity Model Integration (CMMI) guidelines to achieve these capabilities.
A process meta-model is interpreted by CMMI in two different ways: (1) as a continuous model and (2) as a staged model. A process in two dimensions is represented in the continuous CMMI meta-model. Every area of the process (e.g. project planning or requirement) is formally evaluated against particular objectives and practices and is assessed according to the following levels of capability:
Level 0: Incomplete The basic process (e.g., requirements management) is either not carried out or does not fulfill any of the CMMI level capability targets and objectives.
Level 1: Performed All of the basic process area objectives (as specified by the CMMI) have been fulfilled. Work tasks necessary for the development of specified work products are carried out.
Level 2: Managed All Level I requirements have been met. Besides, all work related to the process area conforms to an organizationally defined policy; all people doing the job have access to sufficient resources to get the job done; stakeholders are actively involved as needed in the process area; all work activities and work items are' tracked, managed, and reviewed; and are assessed for adherence to the definition of the process.'
Level 3: Define All Level 2 standards have been met. Besides, the process is "tailored according to the organization's tailoring guidelines from the organization's set of standard processes and provides work products, measures, and other process-improvement information to the assets of the organizational process."
Level 4: Quantitative managed All requirements for level 3 have been fulfilled. Furthermore, using calculation and quantitative evaluation, the process area is monitored and enhanced. "Quantitative quality and process performance objectives are set and used as criteria in the management of the process."
Level 5: Optimized All Capability Level 4 requirements were met. Besides, quantitative (statistical) means are used to adjust and refine the process area to meet evolving consumer expectations and to continuously increase the effectiveness of the process area under consideration.
In terms of "specific objectives" and the "specific practices" necessary to achieve these goals, the CMMI describes each process region. Specific objectives describe the features that must occur if the operations indicated by a process area are to be efficient. Specific practices simplify a target into a series of activities linked to the method.
Key takeaway :
- A process in two dimensions is represented in the continuous CMMI meta-model.
- A process meta-model is interpreted by CMMI in two different ways: as a continuous model and as a staged model.
● A specified collection of process elements and a consistent flow of process work are described by prescriptive process models.
● The approach to the prescriptive process in which order and continuity of projects are the dominant (main) issue.
● "Prescriptive" means that a series of process elements are prescribed for each project - framework operations, software engineering actions, assignments, work materials, quality assurance, and change control mechanisms.
● To bring order to the chaos (disorder) of software development, prescriptive process models were originally proposed.
● A process flow (often called a workflow) is also provided by each process model - that is, the way the process components are interrelated to each other.
Winston Royce introduced the Waterfall Model in 1970. This model has five phases: needs analysis and specification, construction, implementation, and evaluation of units, integration and system evaluation, and implementation and maintenance. The steps always follow this way and are not consistent. The developer must complete all stages before the start of the next phase. This model is called the “Waterfall Model” because its graphic representation is similar to the fall of a waterfall.
1. Requirements analysis and specification phase: This phase aims to understand the exact requirements of the customer and to document them properly. It describes the “what”; of the system to be produced and not “how. “In this phase, a large document called Software Requirement Specification (SRS) document is created which contained a detailed description of what the system will do in the common language.
2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a suitable form that permits further coding in a programming language. It defines the overall software architecture together with a high level and detailed design. All this work is documented as a Software Design Document (SDD).
3. Implementation and unit testing: During this phase, the design is implemented. If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the information needed by software developers is contained in the SDD.
4. Integration and System Testing: This phase is highly crucial as the quality of the end product is determined by the effectiveness of the testing carried out. However, in this phase, the modules are tested for their interactions with each other and with the system.
5. Operation and maintenance phase: Maintenance is the task performed by every user once the software has been delivered to the customer, installed, and operational.
Fig 3: waterfall model
Advantages of the Waterfall model
● All phases are clearly defined.
● One of the most systematic methods for software development.
● Being the oldest, 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.
● The high amount of risk and uncertainty.
● A 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 new systems, having such unchanging requirements is not possible.
Key takeaway :
- The developer must complete all stages before the start of the next phase.
- Simple and simple to comprehend and use.
- Due to the rigidity of the model, it is simple to handle.
- Phases are processed one at a time and completed.
An Incremental model is a software development process where the requirements are divided into multiple independent software cycle modules. In this model, each module goes through the stages of need, construction, implementation, and testing.
All subsequent releases of the module can add a function to the previous release. The process continues until a complete plan is found.
The various phases of the incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the requirements. And the system functional requirements are understood by the requirement analysis team. To develop the software under the incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the development method are finished with success. When software develops new practicality, the incremental model uses style and development phase
3. Testing: In the incremental model, the testing phase checks the performance of each existing function as well as additional functionality. In the testing phase, various methods are used to test the behaviour of each task.
4. Implementation: The implementation phase enables the coding phase of the development system. It involves the final coding that design in the designing and development phase and tests the functionality in the testing phase. After completion of this phase, the number of the product working is enhanced and upgraded up to the final system product.
Fig 4: Incremental model
Key takeaway :
- Each module goes through the stages of need, construction, implementation, and testing.
- To develop the software under the incremental model, the Requirement phase performs a crucial role.
- When software develops new practicality, the incremental model uses the style and development phase.
The evolutionary process model resembles the iterative enhancement model. The same phases are defined for the waterfall model occurs here in a cyclical fashion. This model differs from the iterative enhancement model in the sense that this does not require a useful product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority.
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 m A but will exhibit less capability than C
● As the system is viewed to be developed incrementally so it is also termed as an incremental model of development
Fig 6: Evolutionary model of software 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
Key takeaway:
● The evolutionary model is 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.
● It is also called concurrent engineering.
● The simultaneous model facilitates the iterative and concurrent representation of the process model by a software team.
● For instance, by invoking one or more software engineering actions: prototyping, analysis, and design, the modeling activity specified for the spiral model is accomplished.
● The activity - modeling - can be noted at any given time in any of the states.
● Similarly, in a similar way, other events, acts, or assignments.
● Both software engineering operations occur simultaneously but are located in different states.
Fig 7: a concurrent process model
For all forms of software development, concurrent modeling is applicable and gives an accurate image of the current state of a project. It describes a process network rather than confining software engineering operations, actions, and tasks to a series of events. Each network operation, action, or task occurs concurrently with other activities, actions, or tasks. Events created at one-point trigger transitions between the states in the process network.
The communication activity has completed its first iteration early in a project, for example, and remains in the state of awaiting changes. The modeling activity (which existed in the inactive state after the initial communication) is now moving to the state under progress.
Key takeaway :
- concurrent modeling is applicable and gives an accurate image of the current state of a project.
I have already noticed that modern software for computers is marked by constant change, very tight timelines, and an urgent need for customer satisfaction.
In certain situations, the most significant management criterion is time-to-market. The software project itself will be useless if a business window is missed. To solve these problems, evolutionary process models were conceived, and yet, as a general class of process models, they still have limitations.
We have some doubts, considering the unquestionable advantages of evolutionary software processes.
The first issue is that, because of the unknown number of cycles needed to construct the product, prototyping [and other more complex evolutionary processes] presents a challenge for project planning. Most methods of project management and estimation are based on linear activity layouts, but they do not suit perfectly.
Second, the optimum speed of evolution is not determined by evolutionary software processes. Without a time of rest, if changes happen too soon, the process will certainly collapse into chaos. On the other hand, if the pace is too slow, then it could impact efficiency.
Third, rather than high efficiency, software processes should be based on versatility and extensibility. This statement sounds frightening. We can, however, prioritize the speed of growth over zero defects.
A common iterative and gradual software development process system is the unified software development process or unified process. The Logical Unified Method is the most accepted and thoroughly documented enhancement of the Unified Process (RUP).
The Unified Process is not just a system, but rather an expandable structure that can be adapted to particular organizations or projects. Similarly, a customizable system is the Logical Unified Method.
Fig 8: unified process phases
Characteristics of the Unified process :
An iterative and gradual method of growth is the Unified Process. Several timeboxed iterations are split into the Elaboration, Development, and Transformation phases. (For a large project, the Inception stage can also be split into iterations.)
The consequence of each iteration is an increment, which is a device release that incorporates additional or enhanced features compared to the previous release.
While several iterations would involve work in most disciplines of the method (e.g. specifications, design, implementation, testing), throughout the project, the relative commitment and focus will shift.
II. Use case Driven
Use cases are used in the Centralized Phase to capture the functional specifications and to determine the content of the iterations. Each iteration takes a collection of use cases or scenarios through implementation, test, and deployment, from requirements.
III. Architecture Centric
The Cohesive Method maintains that design is at the core of the attempts of the project team to form the scheme. Because no single model is enough to cover all aspects of a structure, multiple architectural models and views are enabled by the Unified Method.
IV. Risk Focused
Early in the project life cycle, the Cohesive Process allows the project team to concentrate on managing the most important risks.
To ensure that the greatest risks are tackled first, the deliverables of each iteration, particularly in the development phase, need to be chosen.
V. Project Lifestyle
The project is divided into four stages by the Unified Process:
Inception is the smallest stage in the project, and it should hopefully be very brief. It could be a sign of unnecessary up-front requirements if the Inception Period is long, which is contrary to the Cohesive Process spirit.
For the Inception process, the following are common objectives.
For the project, create a justification or business case
Prepare a project preliminary schedule and estimate of costs
Identify risks
The project team is expected to catch a healthy majority of the device specifications during the Elaboration Process. However, Elaboration's primary goals are to resolve identified risk factors and to develop and validate the architecture of the system. The generation of use case diagrams, conceptual diagrams (class diagrams with only basic notation), and package diagrams are common processes carried out in this phase (architectural diagrams)
The biggest step of the project is constructed. The rest of the framework is based on the foundation laid down in Elaboration in this stage. In a sequence of brief, timeboxed iterations, device features are introduced. An executable release of the program results in each iteration. During the construction process, it is customary to write full-text use cases and each one becomes the start of a new iteration.
Transition is the ultimate project phase. The system is deployed to the target users in this process. In the course of many Transition step iterations, feedback obtained from an initial release (or initial releases) may result in further refinements to be implemented.
Fig 9: Project lifecycle
Key takeaway -
- In comparison to the Rational Unified Process, the term Unified Process is commonly used to identify the generic process, including those elements common to most refinements.
- The final deliverable planning phase is a plan for the construction phase (including cost and timeline estimates).
- During the construction process, it is customary to write full-text use cases and each one becomes the start of a new iteration.
- The Milestone for the Product Release marks the conclusion of the Transition process.
1.18.1 Agile methods
The Iterative Waterfall model was very common in earlier days to complete a project. But today, when using it to create a program, developers face different problems. During project growth, the key challenges included managing change requests from clients and the high cost and time needed to implement these changes. To counter these limitations of the Waterfall model, the Agile Software Development model was proposed in the mid-1990s
The Agile model was primarily designed to help a project to adapt to change requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. Agility is necessary to achieve this mission. Agility is accomplished by adapting the approach to the project, eliminating behaviours that may not be important for a particular project. Something that is a waste of time and money is also stopped.
The Agile model applies to a community of production processes. Such procedures share certain fundamental features, but there are some subtle variations between them. Below are a few Agile SDLC models –
● Crystal
● Atern
● Feature-driven development
● Scrum
● Extreme programming (XP)
● Lean development
● Unified process
The specifications are decomposed into several small parts in the Agile model that can be built gradually. Iterative production is embraced by the Agile model. Over an iteration, each incremental component is created. Each iteration is intended to be small and simple to handle, and can only be completed in a few weeks. One version is scheduled, produced, and deployed to the clients at a time. They do not make long-term plans.
The fusion of iterative and incremental process models is the Agile model. In agile SDLC models, the steps involved are:
● Requirement gathering
● Requirement Analysis
● Design
● Coding
● Unit testing
● Acceptance testing
The time for an iteration to be completed is known as a Time Box. The time-box refers to the maximum amount of time available for clients to deliver an iteration. So, it does not change the end date for an iteration. But, if required to produce it on time, the development team may decide to decrease the supplied functionality during a Time-box.
Key takeaway:
● The basic concept of the Agile model is that the consumer receives an increase after each time box.
● The Agile model applies to a community of production processes.
● Agility is accomplished by adapting the approach to the project, eliminating behaviours that may not be important for a particular project.
1.18.2 Plan driven and Agile Development
Plan-driven procedures are systems in which all process operations are carried out.
Designed in advance, and progress toward this strategy is calculated. Different device types include various software processes.
In the software process, agile approaches to software development consider design and execution to be the core activities. They introduce other tasks into the design and execution, such as the elicitation and testing of specifications.
By comparison, a software engineering plan-driven approach describes different phases in the software process with outputs associated with each step. As a basis for planning the following process operation, the outputs from one stage are used.
Iteration happens through tasks in an agile approach.
The specifications and the design are thus established together, rather than separately. Not necessarily a waterfall model of a plan-driven software operation, plan-driven, incremental development, and execution is feasible.
Allocating criteria and planning the design and development process as a sequence of increments is perfectly feasible. An agile process is not inevitably code-focused and some design documentation may be created.
Not necessarily a waterfall model of a plan-driven software operation, plan-driven, incremental development, and execution is feasible. It is entirely feasible to assign specifications and schedule the design and development process as a sequence of increments.
Fig 10: plan-driven and Agile development
There are components of plan-driven and agile processes in most projects. It depends on technological, human, and organizational issues to determine the balance:
2. Is an incremental distribution approach practical, where the software developer delivers the software to customers and receives fast input from them? Consider using agile strategies if so.
3. To help device growth, what technologies are available? Agile techniques rely on good instruments to keep track of a changing architecture
4. What kind of scheme is being created? For programs that require a lot of study before implementation, plan-driven approaches might be needed (e.g. real-time system with complex timing requirements).
5. What is the predicted lifetime of a system? To convey the original goals of the system developers to the support team, longer-life systems can require further design documentation.
6. How big is the scheme that is being created? Where the framework can be built with a small co-located team who can communicate informally, agile approaches are most successful. For complex systems that need larger development teams, this may not be feasible, so a plan-driven approach may have to be used.
Key takeaway :
- In the software process, agile approaches to software development consider design and execution to be the core activities.
- An agile process is not inevitably code-focused and some design documentation may be created.
- Iteration happens through tasks in an agile approach.
References:
