Chapter 2 - Software Processes PDF

Chapter 2 – Software Processes Chapter 2 Software Processes 1 Topics covered  Software process models  Process activities Chapter 2 Software Processes 2  The systematic approach that is used in software engineering is sometimes called a software process....

Chapter 2 – Software Processes Chapter 2 Software Processes 1 Topics covered  Software process models  Process activities Chapter 2 Software Processes 2  The systematic approach that is used in software engineering is sometimes called a software process.  A software process is a sequence of activities that leads to the production of a software product. There are four fundamental activities that are common to all software processes. These activities are: 3  Software Process Fundamental Activities 1. Software Specification (Requirements), where customers and engineers define the software that is to be produced and the constraints on its operation. 2. Software Development, where the software is designed and programmed (Design and implementation (Code)). (Creating Models (class diagram, flow charts, use cases, interactions, algorithms, internal structure, data to be used, etc.), then Programming (new or reuse). 3. Software Validation (Testing), where the software is checked to ensure that it is what the customer requires. 4. Software Evolution, where the software is modified to reflect changing customer and market requirements. (Management and Documentation are ongoing activities that are aligned with the previous activities). 4 The software process  In practice, they are complex activities and may include sub-activities (e.g. requirements validation, unit testing).  Also, there are supporting activities (e.g. documentation and software configuration management). 5  Software process descriptions  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.  However, Process descriptions may also include:  Products, which are the outcomes of a process activity; E.g. the outcome of architectural design is a model of software architecture.  Roles, which reflect the responsibilities of the people involved in the process; (e.g. Project Manager, Configuration Manager, Programmer). Chapter 2 Software Processes 6  Software process descriptions  Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. For example, before architectural design begins, a pre- condition may be that all requirements have been approved by the customer; after this activity is finished, a post-condition might be that the UML models describing the architecture have been reviewed. Chapter 2 Software Processes 7  Plan-driven and agile processes  Plan-driven processes are processes where all of 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.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are no right or wrong software processes. Chapter 2 Software Processes 8  Different types of systems need different development processes.  For example, real-time software in an aircraft has to be completely specified before development begins.  In e-commerce systems, the specification and the program are usually developed together.  Consequently, these generic activities may be organized in different ways and described at different levels of detail depending on the type of software being developed. 9  Software process models  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. and thus provides only partial information about that process. For example, a process activity model shows the activities and their sequence but may not show the roles of the people involved in these activities. Chapter 2 Software Processes 10 Software process models 1. The waterfall model  Plan-driven model. Separate and distinct phases of specification and development. 2. Incremental development  Specification, development and validation are interleaved. May be plan- driven or agile. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. 3. Reuse-oriented software engineering  The system is assembled from existing components. May be plan-driven or agile.  In practice, most large systems are developed using a process that incorporates elements from all of these Chapter 2 Software Processes 11 models. The waterfall model A Sequential Approach. In the waterfall model, you must plan and schedule all of the activities before starting working on them (plan-driven process). Chapter 2 Software Processes 12 Waterfall model phases Chapter 2 Software Processes 13 Waterfall model problems Chapter 2 Software Processes 14  However, there are some areas where Waterfall model was continued to be preferred.  Consider a system where human life is on the line, where a system failure could result in one or more deaths.  Consider a system where time and money were secondary considerations and human safety was first.  Development of Department Of Defense (DOD), military and aircraft programs followed Waterfall model in many organizations. This is because of the strict standards and requirements that have to be followed.  In such industries, the requirements are known well in advance and contracts are very specific about the deliverable of the project. Chapter 2 Software Processes 15  Incremental development  Incremental development is based on the idea of developing an initial implementation, exposing this to user feedback, and evolving it through several versions until an acceptable system has been developed.  The activities of a process are not separated but interleaved with feedback involved across those activities. 16  Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality.  This means that the customer can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments.  Incremental software development is better than a waterfall approach for most business, e-commerce, and personal systems. Chapter 2 Software Processes 17 Incremental development benefits  The cost of accommodating changing customer requirements is reduced.  The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model.  It is easier to get customer feedback on the development work that has been done.  Customers can comment 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 are able to use and gain value from the software earlier than is possible with a waterfall process. Chapter 2 Software Processes 18  Incremental development problems  From a management perspective, the incremental approach has two problems:  The process is not visible.  Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.  System structure tends to degrade as new increments are added.  Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Chapter 2 Software Processes 19 The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system. Large systems need a stable framework or architecture and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture. This has to be planned in advance rather than developed incrementally. Chapter 2 Software Processes 20 Reuse-oriented software engineering Chapter 2 Software Processes 21 There are basically three types of software components that can be used in a reuse-oriented process: Web services that are developed according to well-known service standards and which will become available for remote invocation. Collections of objects that are developed as a package to be integrated with a component framework such as.NET or Java EE. Standalone software systems that are configured for use in a particular environment. 22 Coping With Change  Change is inevitable in all large software projects:  The system requirements change as the business procuring the system responds to external pressures and management priorities change.  As new technologies become available, new design and implementation possibilities emerge. Therefore whatever software process model is used, it is essential that it can accommodate changes to the software being developed.  Change adds to the costs of software development because it usually means that work that has been completed has to be redone. This is called rework. 23  Software prototyping  A prototype is an initial version of a system used to demonstrate concepts and try out design options.  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. ** Back-to-back testing is a type of testing which is conducted if there are two or more variants of components with similar functionality. It is also called Comparison Testing. The aim of back-to-back testing is comparing the results to check if there are any divergences in the work. 24 Benefits of prototyping  Improved system usability.  A closer match to users’ real needs.  Improved design quality.  Improved maintainability.  Reduced development effort. Chapter 2 Software Processes 25 The process of prototype development Chapter 2 Software Processes 26