Understanding Software Development Processes and Models
i. Feasibility Study: An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The study considers whether the proposed systems will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more detailed analysis. Technical, commerce, financial, team.
ii. Software Prototyping: A version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of some design decisions. This supports change avoidance as it allows users to experiment with the system before delivery and refine their requirements. The number of requirements change proposals made after delivery is therefore likely to be reduced. Easy to get feedback. Types include:
- Throwaway prototype
- Incremental prototype
i. Validation and Evolution: Software validation checks if the software does what the customer wants; on the other hand, software evolution means that the software must evolve to meet changing customer needs. Software evolution needs strong validation in order to adapt perfectly to these constant changes.
ii. Plan-Driven and Agile (Active) Processes: A plan-driven approach to software engineering identifies separate stages in the software process with outputs associated with each stage. The outputs from one stage are used as a basis for planning the following process activity. In a plan-driven approach, iteration occurs within activities with formal documents used to communicate between stages of the process. For example, the requirements will evolve, and ultimately, a requirements specification will be produced. This is then an input to the design and implementation process. In an agile approach, iteration occurs across activities. Therefore, the requirements and the design are developed together, rather than separately.
A plan-driven software process can support incremental development and delivery. It is measured with milestones; some problems are that it is expensive, requires changes to everything, is sequential, and has delivery times. An agile process is not inevitably code-focused and may produce some design documentation. As discussed in the following section, the agile development team may decide to include a documentation ‘spike’, where, instead of producing a new version of a system, the team produces system documentation. Planning is incremental, easier to change, and reflects customer requirements. Some problems are: difficult to test, uncertainty about which process/step you are in, and changes to the internal data structure.
– Software Process: Each software process has different needs and different ways to proceed in order to achieve these needs. However, there are four main activities that must be done at all times. These activities are:
- Software Specification: The functionality of the software and constraints on its operation must be defined.
- Software Design and Implementation: The software to meet the specification must be produced.
- Software Validation: The software must be validated to ensure that it does what the customer wants.
- Software Evolution: The software must evolve to meet changing customer needs.
– Objects of Software Process: There are three main process descriptions: products, roles, and pre- and post-conditions. The products are the outcomes of a process activity. For example, the outcome of the activity of architectural design may be a model of the software architecture. The roles reflect the responsibilities of the people involved in the process. Examples of roles are project manager, configuration manager, programmer, etc. Finally, the pre- and post-conditions 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.
Waterfall Model: A plan-driven model with separate and distinct phases of specification and development. Advantages: A phase has to be completed before going to the next one. Each phase provides information for problem identification. Each document generated must be modified to reflect the changes made. With each document, the process becomes visible and can be monitored and compared with the development plan. It is mostly used for large projects where the system is developed several times. Disadvantages: Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase. 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. In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.
Incremental Development: Specification, development, and validation are interleaved. It may be plan-driven or agile. Each system develops a version, and each version adds functionality to the last version. Benefits:
- Less documentation modification in comparison with the waterfall model.
- It’s easier to get feedback from the client about the development done.
- It is possible that this model is faster in the delivery and implementation of the system.
Problems: From an administrative perspective, it has two problems: the process is not visible, so it can be difficult to measure progress, and the incorporation of changes in the software becomes more difficult and expensive. The structure of the systems tends to degrade as new increments are added.
Reuse-Oriented: The system is assembled from existing components. It may be plan-driven or agile. COTS (Commercial off the shelf). In practice, most large systems are developed using a process that incorporates elements from all of these models. This model prioritizes the reuse of software. It is divided into four phases:
- Component analysis
- Modification of requirements
- Design the system with reutilization
- Developing and integrating
There are three types of components that are used in the reutilization process:
- Web services developed to attend standard services and are remotely available.
- Collection of objects developed like a package for integration with a component framework like .NET and J2EE.
- Stand-alone software systems that are configured to be used in a particular scenario.
Explain the main features of “A General Model of the Design Process”: Design activities may be performed through various stages. Discuss each stage. The logical stages of the design process have to start “from the bottom to the top.” The first stage is the 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. This interface specification must be unambiguous. With a precise interface, a component can be used without other components having to know how it is implemented.
Once interface specifications are agreed, the components can be designed and developed concurrently. Component design, where you take each system component and design how it will operate. This may be a simple statement of the expected functionality to be implemented, with the specific design left to the programmer. Alternatively, it may be a list of changes to be made to a reusable component or a detailed design model. The design model may be used to automatically generate an implementation. Database design, where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created.
Software Validation and Verification: Software validation and verification helps by knowing if the system both conforms to the specifications and meets the system customer’s needs. The principal validation technique is software testing. Development testing: The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components. Test automation tools that can re-run component tests when new versions of the component are created are commonly used. System testing: System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems. It is also concerned with showing that the system meets its functional and non-functional requirements, and testing the emergent system properties. Acceptance testing: The system is tested with data supplied by the system customer rather than with simulated test data. Acceptance testing may reveal errors and omissions in the system requirements definition.
Acceptance testing may also reveal requirements problems where the system’s facilities do not really meet the user’s needs or the system performance is unacceptable. Prototyping: It allows the user to see how well the system helps in their job. The user can get new ideas for requirements and identify areas of strength and weaknesses. Lower risk of failure: Check system functionality earlier and prioritize functions first.
Throwaway Prototypes: Prototypes created iteratively to check the customer’s requirements and the feasibility of some design decisions. While they are being used and tested, they help in getting feedback to improve the creation of new prototypes, and in the end, the final product. As they are representations of the system, they should be simple, with easy ways of being modified, and they should be easy to develop. Discard prototypes: Undocumented, impossible to implement. Better to discard it than to fix it.
Incremental Delivery: Where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. It avoids the premature commitment to requirements for the whole system and allows changes to be incorporated into later increments at relatively low cost. Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail, and that increment is developed. During development, further requirements analysis for later increments can take place, but requirements changes for the current increment are not accepted. Once an increment is completed and delivered, customers can put it into service. As new increments are completed, they are integrated with existing increments so that the system functionality improves with each delivered increment.