It’s impossible to run the modern world without software. Millions of once human-driven infrastructure and utility-based systems around the world are now automated, sequenced and monitored by computer-controlled software systems.
Think about the objects you use and interact with daily. What controls them? How do they operate? Everything from the music industry, movies, and theatre, to manufacturing, transport, finance, and food production are all software intensive and have been developed using a complete set of software life-cycle requirements.
You should also note that very few of these systems are different and require different methods and techniques because different software development requires different approaches. Although they all require software engineering, they do not all require the same engineering techniques.
This means that software engineers and developers are essential for the future functioning of millions of towns, cities, and communities around the world.
Let’s look a little deeper to expand your understanding around software, computer programs, developers, and engineering.
Two kinds of software products
Generic products are stand-alone systems that are produced by a development organization and sold on the open market. These include, database, word processors, project management tools, or file management systems. Also think contemporary programs, games, apps, and fitness trackers.
Customised (or bespoke) systems are usually commissioned by a customer. The software is designed by a team of software developers specifically for that customer’s needs. These might be control systems for electronic devices, systems that support business processes or air traffic control systems. These are built using teams of people and lots of collaboration with the customer. These include mobile apps for business such as banks, credit and financial firms, customer shopping apps and weather apps.
Just like building any type of structure, physical or otherwise, there is a systematic approach that is used in software engineering called a system process. This process is part of a Software Development Life Cycle which encompasses activities from the initial design to the final implementation and testing. In this topic we also use the term software process which is the steps taken while designing and developing software.
Software is a collection of executable programming code, associated libraries, and documentation. Software development is also known as software engineering due to all the engineering concepts pertaining to development software that are applied.
Tsui and Safari in The Essentials of Software Engineering (3rd edition) describe the software development process as:
The set of tasks, the sequence and flow of these tasks, the inputs to and the outputs from the tasks, and the pre-conditions and post-conditions for each of the tasks involved in the production of a software.
A process helps guide and coordinate people so they can manage complex projects that involve multiple developers to produce a consistent and cohesive design. Where a project requires multiple people, it is essential they all understand the sequence, starting conditions, constraints and any overlaps that may occur.
These processes in general terms include:
- Specification – defining what the system should do
- Design and implementation – defining the organization of the system and implementing the system (designed and programmed)
- Validation – checking that it does what the customer wants
- Evolution – changing the system in response to changing customer needs.
A software process model is an abstract representation of a process. It presents a description of a process from a particular perspective.
Let’s quickly look at what it takes to write a program under the headings above:
Specification
These can be described as the program requirements. It also means the constraints or boundaries in which the program can be designed and implemented. You will need to understand what a program needs to do and how it must function. Functionality means what the program will do and is measured in terms of performance, usability, and maintainability. Will it sort a file, display information on the screen when required and perform a calculation? And just as important, is the user experience a good one, does it do what the user needs it to do?
Design and Implementation
The design phase comes once there is a clear understand of the wants and needs of the customer. This is where the process of designing a program within the constraints begins. Decisions such as user interface, platforms that the program will run on, compatibility and program languages, estimated program inputs, algorithms and scheduling requirements or completing the project all need to be addressed. And just as important is the implementation stage. Even if all these pieces are in place and working, a bad implementation will mean a bad program and a less than satisfactory user experience.
Validation
Testing the program is always a good idea, and this is done while the program is being developed and once it is completed. Developers should always run their own tests prior to client testing to ensure the program works! If client testing fails, you risk the client rejecting the program altogether.
Evolution
The relationship with a client moves beyond the implementation and allows for a trial period where the program is monitored and adjusted where needed. Software in the public domain is often offered out first as a trial (or beta) version which allows for users to feedback on any problems and issues they encounter. This gives developers the opportunity to update and plug any gaps found in the software program while exposing the program to multiple users over different platforms. Supporting a client during this time is an integral part of the software development process.
Process Activities
The framework used to develop new software describes the activity performed at each stage of software development. Real software processes are inter-leaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing and testing a software system.
The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. Each model will have its own unique system of progressing through a development cycle.
Types of software components that may need developing or redesigning:
- Web services that are developed according to service standards and which are available for remote invocation.
- Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
- Stand-alone software systems (COTS) that are configured for use in a particular environment.
Software Specification
The process of establishing what services are required and the constraints on the system’s operation and development.
Requirements of engineering/development process:
- Feasibility study: Is it technically and financially feasible to build the system?
- Requirements elicitation and analysis: What do the system stakeholders require or expect from the system?
- Requirements specification: Defining the requirements in detail
- Requirements validation: Checking the validity of the requirements
The engineering requirements process
The system architecture describes its technical description and represents the complete set of the software development life cycle (SDLC) requirements. The model shows reflects the developer’s understanding of how parts influence, cooperate and collaborate with each other within the whole project.
Watch the video from Destin Learning which outlines the steps involved in the SDLC before we move on the processes involved.
Software process models
When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities.
Process descriptions may also include:
- Products, which are the outcomes of a process activity
- Roles, which reflect the responsibilities of the people involved in the process
- Pre-and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.
Plan Driven and Agile processes
Some points to be aware of:
- Plan-driven processes are processes where all the process activities are planned in advance and progress is measured against this plan.
- In agile processes, planning is incremental, and it is easier to change the process to reflect changing customer requirements. The agile methodology is covered in another topic, but you may see references to it here.
- In practice, most practical processes include elements of both plan-driven and agile approaches.
- There are no right or wrong software processes.
Remember a software process model is an abstract representation of the software development process and should link all the elements of the cycle together. The goal of a development process model is to provide guidance and help coordinate tasks to achieve a result as effectively as possible.
A model should define the following:
- The tasks to be performed
- The input and output of each task
- The pre and post conditions for each task
- The flow and sequence of each task
And the model should include the following stages:
Stage 1
- Requirement gathering – a feasibility report that is positive towards the project and gather the requirements from the user. Both clients and end users know what they want and what features are to be included.
Stage 2
- Software design is a process to transform user requirements into a suitable form. There is a need for more specific and detailed requirements and the output of the process can directly be used in implementation in a programming language. Here are three levels of design:
- Architectural – the highest abstract version of the system. Many components interact with each other.
- High level design – focuses on how the system along with all the components can be implemented in the form of modules.
- Detailed design – defines he logical structure of each module and its interface to communicate between each other.
Stage 3
In this phase you will see how the produce will be developed. This is one of the most crucial parts and is known as the implementation phase.
Stage 4
Product testing and integration will integrate the modules and test the overall product using different testing techniques.
Stage 5
Deployment and maintenance where the actual deployment of the product and continued maintenance of the software for all future updates, and/or additional features that may be added.
A system represents a complex human-made product that involves the use of hardware, software, and human operators for it to work effectively. Therefore, its important that the final product must be understood in relation to the complete range of activities and steps of the life cycle process. These all impact the feasibility of the potential solutions on the original design.
Let’s look at some of the common models used in the software development life cycle (SDLC).
The waterfall model
Plan-driven model where you must plan and schedule all the activities before beginning the project. Each activity is represented as a separate and distinct phase of specification and development arranged in linear order.
There are separate identified phases in the waterfall model:
- Requirements analysis and definition
- System and software design
- Implementation and unit testing
- Integration and system testing
- Operation and maintenance
In principle, a phase must be complete before moving onto the next phase, but in reality, these phases are likely to overlap and feed information to the next phase. The model is easy to follow and understand. It doesn’t require a lot of customer input.
An in-action model might look something like this:
The main drawback of the waterfall model is the inflexibility of adapting to change after the process is underway and there is no way to test the or fix the product until the very last phase.
Waterfall model problems:
The waterfall model is known for its inflexible partitioning of the project into distinct stages. This makes for difficult interaction with the client and respond their changing requirements.
- Therefore, this model is only appropriate when the requirements are well understood, and changes will be fairly limited during the design process.
- Few business systems have stable requirements.
The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites where the requirements are understood completely and unlikely to change radically. In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.
Incremental Model
This model divides the functionality of a system into small increments to be delivered one after the other in quick succession. It begins with the most important function then subsequent increments expand on the previous ones until everything is updated and implemented. This method allows for user feedback and for the program to evolve through version control if necessary. It contains an element of risk assessment and containment. If a component runs into trouble the other components can still continue with development independently.
Incremental development benefits:
- The cost of accommodating customer changes is reduced.
- The amount of analysis and documentation that must be reworked is a lot less than what’s required using the waterfall model.
- It is easier to get customer feedback on the development work already done.
- Customers can feedback on demonstrations of the software and see how much has been implemented.
- More rapid delivery and deployment of useful software to the customer is possible.
- Customers can use and gain value from the software earlier than is possible with a waterfall process.
- Each iteration passes through the requirements of design, coding, and testing stages.
Incremental development problems:
- The process is not visible.
- Managers need regular deliverables to measure progress. Where systems are developed quickly, it is not cost-effective to create user documents that reflect every version of the system.
- System structure tends to degrade as new increments are added.
- Unless time and money are spent on refactoring to improve the software, regular change can corrupt its structure. Making further software changes becomes increasingly difficult and costly.
Boehm’s Spiral model
This model evolved when there were concerns with the waterfall model’s document driven approach. The Spiral model was proposed by Barry Boehm about 1988 and is based on experiences with very large government and corporate businesses. An important part of this model is the emphasis on risk reduction in the software development. A program goes through cycles of development which develops the program in incremental periods.
Spiral model sectors:
- Objective setting: Specific objectives, alternatives and constraints for the phase are identified.
- Risk assessment and reduction: Risks are assessed, alternatives evaluated and activities put in place to reduce the key risks.
- Development and validation: A development model for the system is chosen which can be verified and lead to the next level of production.
- Planning: The project is reviewed, and the next phase of the spiral is planned.
The Spiral model has been very influential in helping people think about iteration in software processes and introducing the risk-driven approach to development. In practice, however, the model is rarely used as published for practical software development.
- Process is represented as a spiral rather than as a sequence of activities with backtracking.
- Each loop in the spiral represents a phase in the process.
- No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.
- Risks are explicitly assessed and resolved throughout the process.
Because this model relies on risk assessment expertise, not all software engineers are trained or experienced in risk identification or risk analysis.
The V-model
This model is known as the verification and validation model. It is characterised by a corresponding testing phase for each development stage. V-model joins by a coding test phase. The next phase only starts after completion of the previous phase.
Verification involves static analysis technique or review done without executing code. It’s the process of evaluation to find out whether the specified requirements meet during the product development stage.
Validation involves dynamic analysis (both functional and non-functional) technique testing by executing code. Validation evaluates the software after the completion of the development phase. This is to determine whether it meets customer expectations and needs.
Advantages:
- Simple and easy to understand and use
- Each phase has specific deliverables plus a review.
- Defects found early on in the process.
- Highly disciplined model
Disadvantages:
- High risk and uncertainty
- Not good for complex and object-oriented projects
- Not suitable where requirements are not finalised, and changes need to be made.
Does not handle concurrent events
The Rational Unified Process: RUP
This process originates from the Rational Software Corporation later acquired by IBM. Its origins are rooted in the original 1987 Objectory Process and the 1997 Rational Objectory Process as well as the Unified Modeling Language (UML). RUP is not a single prescriptive process, but rather an adaptable process framework. It’s intended to be worked by the development organisations and software project teams so they can choose the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.
Tsui and Safari in The Essentials of Software Engineering (3rd edition) describe Unified Modeling Language (UML) as an object-oriented modeling language that provides the elements and relationships to model software requirements and design.
The Model:
- Is a modern generic process derived from the work on the UML and associated process.
- Brings together aspects of popular generic process models.
- Normally described from 3 perspectives
- A dynamic perspective that shows phases over time
- A static perspective that shows process activities
- A proactive perspective that suggests good practice.
RUP phases:
- Inception: Establish the business case for the system.
- Elaboration: Develop an understanding of the problem domain and the system architecture.
- Construction: System design, programming, and testing.
- Transition: Deploy the system in its operating environment.
RUP Iteration:
- In-phase iteration: Each phase is iterative with results developed incrementally.
- Cross-phase iteration: As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.
Static Workflows in the RUP:
| Workflow | Description |
|---|---|
| Business Modelling | Processes are modelled using business use-cases. |
| Requirements | Actors who interact with the system are identified and use cases are developed to model the system requirements. |
| Analysis and design | A design model is created and documented using architectural models, component models, object models and sequence models. |
| Implementation | The components are implemented and structured into sub-systems for implementation. |
| Testing | An iterative process carried out in conjunction with implementation. This follows the completion of implementation. |
| Deployment | A product release is created, distributed to users and installed into their workplace. |
| Configuration and change management | Supporting workflow managed changes to the system. |
| Project Management | This workflow supports and manages the system development. |
| Environment | Concerned with managing appropriate software tools to be available to the software development team. |
Good practice with RUPS:
- Develop software iteratively: Plan increments based on customer priorities and deliver highest priority increments first.
- Manage requirements: Explicitly document customer requirements and keep track of changes to these requirements.
- Use component-based architectures: Organize the system architecture as a set of reusable components.
- Visually model software: Use graphical UML models to present static and dynamic views of the software.
- Verify software quality: Ensure that the software meet’s organizational quality standards.
- Control changes to software: Manage software changes using a change management system and configuration management tools.
The Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction, and transition) but separates activities (requirements, analysis and design, etc.) from these phases.
You can learn more about this process here where study.com gives more insight. Watch the video at the top of the page.
Reuse-oriented software engineering
This is also known as reuse-oriented development (ROD). It can be steps of software development for a specific duration in which software is redesigned by creating a sequence of prototypes known as models. Each system is based on the previous one each within a series of defined rules. It’s based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.
Process stages:
- Component analysis: Identify components of the old system that are most suitable to be reused.
- Requirements modification: Understand all the system components.
- System design with reuse: Modify the old system components to achieve the new requirements.
- Development and integration: Integrate the new modified parts into the new system.
Reuse is now the standard approach for building many types of business system. A specific framework is required to categorise components. The reuse system can begin from any segment of an existing cycle, need, planning, coding, design, or analysis, where other models will struggle to blend into an existing framework.
Advantages:
- It can reduce costs of software development.
- Has a lower risk factor.
- Saves time and input.
- Very efficient.
Disadvantages:
- Where old system components aren’t compatible this can impact model integration.
- Compromised resources may lead to a system that does not fulfil the user requirements.
- Reuse-oriented model is not always worked in it’s true form so becomes inefficient and compromised.
There is also a following Reuse Maturity Model which takes the experiences and insights from various developmental organisations. There are levels of maturity, the first being where organisations place their source code into a single project. This single pool of code will hold multiple applications. There is no need to copy source files because there is only project. But there is a limit to how well this will work.
Choosing a model needs consideration just as the actual project development. Udacity has a series of short videos that take you through a process of how to choose the right model for the right job.
Process models summary: Remember the following points when embarking on any SDLC project.
- Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design.
- Processes may be structured for iterative development and delivery so that changes may be made without disrupting the whole system.
- Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.
- General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development.
- Requirements engineering is the process of developing a software specification.
- Design and implementation processes are concerned with transforming a requirements specification into an executable software system.
- Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.
- Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful.
The process of converting the system specification into an executable system involves three important tasks.
- Software design: Design a software structure that realises the specification.
- Implementation: Translate this structure into an executable program.
- Testing/Delivery: Handing over the complete protest tested verified and validated.
The activities of design and implementation are closely related and may be inter-leaved.
A general model of the design process:
Design activities
- Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed.
- Interface design, where you define the interfaces between system components.
- Component design, where you take each system component and design how it will operate.
- Database design, where you design the system data structures and how these are to be represented in a database.
Software validation
Verification and validation are intended to show that a system conforms to its specification and meets the requirements of the system customer. This involves checking and review processes and system testing.
System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used verification and validation activity.
Testing stages:
- Development or component testing
- Individual components are tested independently.
- Components may be functions or objects or coherent groupings of these entities.
- System testing
- Testing the whole system. Testing of emergent properties is particularly important.
- Acceptance testing
- Testing with customer data to check that the system meets the customer’s needs.
Testing phases
Software evolution
Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although a boundary has been put between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. The flow chart below shows the circular system that evolves.
Coping with Change
- Change is inevitable in all large software projects.
- Business changes lead to new and changed system requirements.
- New technologies open new possibilities for improving implementations.
- Changing platforms require application changes.
Change leads to rework so the costs of change include both rework (e.g., re-analysing requirements) as well as the costs of implementing new functionality.
Change avoidance
Where the software process includes activities that can anticipate possible changes before significant rework is required.
- For example, a prototype system may be developed to show some key features of the system to customers.
Change tolerance
Where the process is designed so that changes can be accommodated at relatively low cost.
- This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have to be altered to incorporate the change.
Incremental development and delivery
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised, and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
Incremental development and delivery process:
- Incremental development
- Develop the system in increments and evaluate each increment before proceeding to the development of the next increment
- Normal approach used in agile methods
- Evaluation done by user/customer proxy
- Incremental delivery
- Deploy an increment for use by end-users
- More realistic evaluation about practical use of software
- Difficult to implement for replacement systems as increments have less functionality than the system being replaced.
Incremental delivery
Advantages:
- Customer value can be delivered with each increment, so system functionality is available earlier.
- Early increments act as a prototype to help elicit requirements for later increments.
- Lower risk of overall project failure.
- The highest priority system services tend to receive the most testing.
Disadvantages:
- Most systems require a set of basic facilities that are used by different parts of the system.
- As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.
- The essence of iterative processes is that the specification is developed in conjunction with the software.
- However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.
Software prototyping may be seen as another process model of SLDC and a prototype is an initial version of a system used to demonstrate concepts and try out design options. The practice is not supported by all software engineers who argue that the structure may become too fragile to cope with the additional functionality requirements.
Richard Schmidt states in his Software Engineering, Architecture-Driven Software Development that:
“Prototypes are, by definition, a sample or model built to test a concept or to behave as a design entity. 4 Prototypes mimic or imitate a design entity in an attempt to allow engineers and designers the ability to explore design alternatives, test theories, and confirm engineering expectations. Prototypes serve to enable the specification of the product rather than basing the specifications on a theoretical or contemplated engineering solution. Software prototyping is fundamentally an oxymoron and, as such, is an unprofessional contradiction devised to permit software personnel to focus on coding rather than architecting the software product.”
He then goes on to outline how prototyping can be utilised and be beneficial when approached with a more prudent and ethical focus:
“Software prototyping does serve a purpose in software engineering if used ethically and sparingly. Prototyping the graphical user interface (GUI) is an example of a proper use of a software prototype. The GUI test article can be exposed to human test subjects to gather human– machine interface data that can be used to refine the GUI specification and design motif. Software prototypes should be undertaken prudently to ensure that the information gathered (benefits of prototyping) merits the investment in the prototyping development. That’s right! Prototyping is a form of development, and the software prototype must be properly scoped, specified, designed, and implemented before it can be used to gather engineering data or user feedback. This suggests that many of the rigorous and meticulous practices associated with implementing the software product may be disregarded to reduce the cost of prototype development. However, this lack of rigor relegates the software prototype to a disposable mockup. Fundamentally, no software code developed under prototyping conditions should be utilized within a deliverable software product.”
Prototypes can be helpful when the overall concept of the new software required is not fully understood or incomplete. It allows the client to try, then adjust the plan and software and the process progresses.
A prototype can be used in:
- The requirements engineering process to help with requirements elicitation and validation
- In design processes to explore options and develop a UI design
- In the testing process to run back-to-back tests.
Benefits of prototyping:
- Improved system usability.
- A closer match to users’ real needs.
- Improved design quality.
- Improved maintainability.
- Reduced development effort.
Prototype development:
- May be based on rapid prototyping languages or tools
- May involve leaving out functionality
- Prototype should focus on areas of the product that are not well-understood
- Error checking and recovery may not be included in the prototype
- Focus on functional rather than non-functional requirements such as reliability and security
Throwaway prototypes
Prototypes should be discarded after development as they are not a good basis for a production system:
- It may be impossible to tune the system to meet non-functional requirements
- Prototypes are normally undocumented
- The prototype structure is usually degraded through rapid change
- The prototype probably will not meet normal organisational quality standards
The Evolutionary Prototyping process by Georgia Press is outlined in the video below. Get some perspective on why it is used as an option during the software development process.
Outlining the process standards seems the appropriate way to complete this topic. There are many different software development methods and models available for use and this quest for finding the optimal process can result in different standards which can result in less than optimal outcomes.
It is now accepted that is an organisation manages its processes well the products will be of a good quality. ISO/IEC 12207 standard is one of the popular process standards which was proposed back in 1988 and published in 1995. The standard was created to establish a common framework that could be used internationally to acquire, supply, develop, operate and maintain software.
ISO/IEX 12207 standard consists of three types of processes:
- Primary life cycle processes
- Supporting life cycle processes
- Organisational life cycle processes.
The standard is applicable for all products that may be a software product, software service or a total system.
The New Zealand government standards state:
Establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware. The standard applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Identical to, and reproduced from, ISO/IEC 12207 (2008).
The standard establishes a set of processes for managing the SDLC. It does not prescribe to any specific life cycle model, development methodology, method, modelling approach or technique. The standard instead makes a distinction between a ‘stage’ and ‘process’.
- Stage: a period or phase within the cycle of an entity that relates to the state of its description or realization. A stage is typically a period of time and ends with a primary decision gate.
- Process: A set of interrelated or interacting activities that transforms inputs into outputs. The same process is often recurring within different stages.
There are other standards that you can learn about and these are outlined in the screen shot below from the NZ government standards site.
| Similar Standards | |
|---|---|
|
AS/ NZS 14756:2001 Information technology-Measurement and rating of performance of computer-based software systems |
AS/ NZS 14764:2001 Information technology - Software maintenance |
|
AS/ NZS 15271:1999 Guide for AS/ NZS ISO/IEL 12207 (Software life cycle processes) |
AS/ NZS 150/.12207:2013 Systems and software engineering - Software life cycle processes |
