A software process (also known as software methodology) is a collection of related activities which lead to the software being created. These tasks can include the software development from scratch, or the modification of an existing system.
Any software process must include the following four activities:
- Software specification (or requirements engineering): Define the main functionalities of the software and the constrains around them.
- Software design and implementation: The software is to be designed and programmed.
- Software verification and validation: The software must conforms to it`s specification and meets the customer needs.
- Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.
They provide sub-activities in practice such as validation of specifications, architectural design, unit testing, … etc.
Activities including configuration and change management , quality assurance, project management , user interface, are also supported.
Along with other activities, the aim is to improve the above activities by introducing new techniques , tools, adopting best practices, standardizing processes (so as to and the variability of software processes), etc.
Typically when we speak about a phase we talk about the events in it. A method however also contains the description of the process, which includes:
- Products: The effects of the an operation. Perhaps the product of architectural design may be a model for software architecture, for example.
- Roles: The people involved in the project have their obligations. For example, The project manager, programmer and so on.
- Pre and post conditions: The conditions before and after an operation have to be valid. For example, the precondition of the architectural design is that the specifications have been accepted by the client, whereas the post condition is the diagrams that have been checked to explain the architecture.
Software process is dynamic and it depends on decision making. There is no optimal method and most companies have built a method with their own software.
For example , a company that works on critical infrastructure has a very structured process, while a less formal, flexible process is likely to be more efficient for business processes, to requirements constantly changing.
Software Process Models
A process model for software is a simplified representation of a software operation. From a particular viewpoint, each model represents one mechanism.
We will take a brief look at very general models of the processes. These conceptual models are process abstractions that can be used to describe various approaches to the software creation. You may adapt them and expand them to establish more complex processes.
Some methodologies are often referred to as Software Development Life Cycle ( SDLC) methodologies, although this term may also be used to refer to any methodology more broadly.
The waterfall model is a sequential approach, organized in linear order, where each fundamental operation of a process described as a separate step.
You have to prepare and schedule all of the tasks in the waterfall model before you start working on them (plan-driven process).
Plan-driven approach is a mechanism where all tasks are first prepared, tracking progress toward the schedule. If the method is agile, preparation is gradual and it’s simpler to adjust the process to represent changes in requirements.
Waterfall model phases are: Specifications, Design , Implement, Evaluate, and Maintenance.
The Nature of Waterfall Phases
In theory, the outcome of each step is one or more documents that should be accepted and the next step does not begin before the preceding phase is complete.
However, in fact, these phases overlap and feed information one to another. For example, requirement problems can be defined during design, and some of the design issues can be found during coding etc.
Therefore the software process is not a clear linear process but requires input from one step to the next. Consequently, documents generated during each process can then need to be updated to represent the changes made.
When To Use?
The waterfall model can be implemented in theory only when the specifications are well known and are unlikely to change drastically during development as this model has a relatively rigid framework that makes it relatively difficult to accommodate change while the project is underway.
A prototype is a version of a system or part of the system which was rapidly designed to verify the specifications of the customer or the feasibility of any design decisions.
A prototype is therefore useful when a customer or developer is not sure of the specifications, algorithms, performance, rules of business, response time, etc.
The client is involved in prototyping in the development process which increases the probability that the client will approve the final implementation.
While several designs are being built with the intention that they will be discarded, in other cases it is possible to evolve from prototype to working device.
A software prototype can be used:
A prototype may help with the elicitation and validation of system requirements in requirements engineering.
- It helps users to play with the device, and thus to optimize the needs. They can get new requirement ideas, and find strength and weakness areas in the program.
In addition, as the prototype is created, errors may be discovered and in the specifications. Maybe then updated the specification to represent the changes.
- A prototype may aid in the design of the system to carry out deign experiments to check the viability of a proposed design.
For example, a database design might be prototype-d and checked for the most common user queries to ensure it supports efficient data access.
The phases of a prototype are:
- Establish objectives: The project aims should be made clear from the beginning of the method. Is it validating device specifications, or demonstrating functionality, etc?
- Define prototype functionality: Decide what are prototype inputs and projected outputs. To reduce the prototyping costs and speed up the development process, you can disregard certain features, such as response time and memory use, unless they are important to the project objective.
- Develop the prototype: Designed the initial prototype which only includes user interfaces.
- Evaluate the prototype: When the users are qualified to use the prototype, mistakes in specifications are then discovered. Using the input will enhance both the requirements and the prototype. If changes are made then you may need to repeat steps 3 and 4.
Prototyping is not a stand-alone, complete technique of creation but rather an approach to be used in the sense of a complete methodology (such as gradual, spiral, etc.).
Incremental development is based on the concept of designing an initial implementation, submitting this to user input and improving it through several iterations until an appropriate solution is created.
A process’s operations are not independent but interwoven with the suggestions provided in those operations.
Each increment of the framework represents a piece of the functionality the client needs. In general, the system ‘s early increments should include the features most essential or most urgently needed.
This ensures that the customer can test the system early in the development to see if it provides what’s needed. If not, then only the current increment and probably new features specified for later increments must be modified.
Incremental Vs Waterfall Model
Incremental software creation is ideal for most companies, e-commerce, and personal systems than a waterfall approach.
Incremental improvement of the software makes improvements to the software cheaper and simpler as it is being built.
Incremental architecture has three significant advantages as opposed to the waterfall model:
- The costs of adjusting to changing consumer needs are minimized. The quantity of research and documentation to be redone is much smaller than the waterfall model demands.
- During growth, it is easier to get customer input about the work performed than when the system is completely developed, checked and supplied.
- Faster delivery of useful applications is possible even though not all the features have been added. Customers will use the program earlier than is feasible with the waterfall model and gain value from it.
It can be a plan-driven or agile, or both
Incremental growth is among the most prevalent methods. The approach can either be a plan-driven or agile approach, or both.
The system increases are defined in advance in a plan-driven approach, but in the agile method only the early increments are known, and the creation of later increments depends on the success and customer objectives.
It’s not a problem-free
But, it’s not a problem-free …
- Some organisations have processes that have evolved over time, and can not adopt the iterative or agile model of informality. For example, protocols to ensure that external regulations are correctly enforced by the Program.
- As new increments are introduced, system structure tends to weaken and get compromised as routine changes are implemented. Even if time and resources are spent on refactoring to upgrade the program, more improvements are becoming harder and more expensive.
The spiral model is a risk-driven one where the mechanism is described as a spiral rather than an operation series.
It was designed to integrate the best features from the waterfall and prototype versions, and incorporates a new component; risk assessment.
Every loop in the spiral (from analysis to service-see figure below) represents a step. Thus the first loop could be concerned with the feasibility of the system, the next loop could be concerned with the specification of criteria, the next loop with system design and so on.
Each loop in the spiral is split into four sectors:
- Objective setting: The goals and risks are specified for that step of the project.
- Risk assessment and reduction: A thorough review is performed for each of the known project risks, and measures are taken to reduce the risk. For instance, if there is a risk of the specifications being unacceptable, a prototype could be created.
- Development and validation: After risk assessment a system process model is selected. But if the risk in the user interface is predicted then we need to test the user interface. If the danger itself is in the process of growth then use the waterfall model.
- Planning: The project is reviewed, and a decision is taken as to whether or not to proceed with another loop.
Spiral model has been highly influential in making people think about iteration of software systems and implement risk-driven development approaches. The model is however seldom used in practice.
The Iterative Development Model aims to build a framework across all components by constructing small portions of all the functions.
We create a product that fits the initial requirements, and quickly release it for customer reviews. An early version with limited features essential for developing the market and getting input from customers.
A slice of device functionality is distributed in each phase, moving through the specifications before the deployment.
The phases of iterative development are:
- Inception: The purpose is to build a business case for the method. We should recognise, and describe, all the external entities that will interact with the system. Then use this knowledge to measure the contribution the system provides to the enterprise. Then the project may be cancelled if the contribution is small.
- Elaboration: We gain an understanding of the design and problem domain context, gain the project plan and identify risks.
- Construction: Incrementally fills-in the architecture with production-ready code produced from requirements review, design, implementation , and testing. The system components rely on each other and during this process, they are built in parallel and integrated. You should have a full working program upon completing this process.
- Transition: We apply the framework to the environment in which output operates.
All the phases will be performed once, while the process of development will be visited incrementally with each increment; for every slice of device functionality.
Agility is flexibility; it is a state of dynamic, adapted to the specific circumstances.
The agile approaches apply to a community of software development models focused on the gradual and iterative approach in which changes are small and usually new system releases are produced and made available every few weeks to customers.
|Customer Involvement||Customers should be closely involved in the whole process of growth. Their function is to provide and prioritize new system specifications, and to evaluate system iterations.|
|Incremental Delivery||The program is built in increments with the client defining the specifications for each increment to be included.|
|People not Process||The production team’s expertise should be understood and utilized. The team members should be left without prescriptive mechanisms to establish their own ways of working.|
|Embrace Change||Wait for improvements to the system specifications and then develop the system to accommodate those improvements.|
|Maintain simplicity||Concentrate on simplicity in both the applications being built and remove device complexity|
In the production phase they include customers to make improvements to specifications. They reduce paperwork by using informal correspondence instead of structured written-document meetings.
They are ideally suited for applications where requirements change quickly during the phase of development.
Various agile approaches are available, such as: Scrum, Crystal, Agile Modeling (AM), Extreme Programming ( XP), etc.
Increment Vs Iterative Vs Agile
You may be wondering what the difference is between gradual, iterative and agile models.
— increment in the incremental method builds a complete software function, while it builds small portions of all features in iterative.
An agile approach incorporates the incremental and iterative approach by constructing a small portion of each attribute, one by one, and then adding features gradually and increasing their completeness.
Reuse-oriented Software Engineering
It is attempting to replicate (probably also tested) an existing design or code that is close to what is required. It is then changed, and integrated into the new system.
Although the initial “requirements specification” phase and “validation” phase are similar to other software systems, there are different intermediate phases in a reuse-oriented process. The following stages are:
- Component analysis: A quest is made for the components to fulfill the specification of the given specifications. There is usually no exact match and components can only provide some of the required functionality..
- Requirements modification: During this phase the requirements are analyzed using information about the discovered components. They are then modified to reflect the components which are available. If the modifications are not possible, the activity of the component analysis may be re-entered to look for alternative solutions.
- System design with reuse: The system framework is designed during this phase, or an existing framework is reused. The designers take into account the reused components, and will organize the framework accordingly. Where certain reusable components are not available, some new software must be designed.
- Development and integration: To create the new system, the components are built in. In this model, system integration may be part of the process of development, rather than a separate activity.
There are basically three types of software components that can be used in a reuse-oriented process:
- Web services that are built for remote invocation according to well-known service standards and that will become usable.
- Object collections that are built as a package to be incorporated with a component system like. NET or Java EE.
- Standalone software systems which are configured to be used in a given environment.
It’s has an obvious advantage, But!
Reuse-oriented software engineering has a clear advantage of reducing the amount of software to be developed, thereby minimizing costs and risks, typically resulting in faster delivery.
Compromises with specifications cannot be avoided, however, which can lead to a device that does not satisfy the users’ real needs.
In addition, some control over the development of the system may also be lost as new iterations of the recycled components are not under the control of the company using them.