Software Process

Software ProcessThe software process is the set of actions and related results which produce a software product. These actions are mostly carried out by software developers. CASE is computer-aided software engineering tools are used to help with some process activities. There are 4 basic process activities that are applicable to all software processes.
1) Software specification: The software must define functionality of the software and constraints on its operation. 2) Software development: The software must be developed according to its specification. 3)Software validation: The software must perform all the function that customer wants. 4)Software evolution: The software must develop to meet changing customer requirements.
In software process there is no such thing as a ‘right’ or ‘wrong’ case. Different software processes divide these activities in different ways. The timing and result of the each activity varies as per software process. Using different processes different types of software product may be produced by an organization. However, it may possible that for particular application some processes are more suitable than others type of processes. If the wrong process is used, this will probably decreases the quality or the usefulness of the software product to be developed.
Because there are a number of different processes models are used, it is impossible to produce reliable figures for cost distribution across these activities. However, changing software usually takes up more than 60% of total software costs. This percentage is rising as more and more software is produced and has to be maintained. Designing software for change is vital.
Complex software processes involve a variety of activities. Processes have following attributes or characteristics:
1)Understandability : To what level is the process explicitly defined and how easy is it to understand the process definition?
2)Visibility: Does the process activity culminate in clear results so that the progress if the process is externally visible.
3)Supportability: To what level can be process activities be supported by CASE tools
4)Acceptability: Is the process acceptable to and usable by the engineers responsible for producing the software product?
5)Reliability Is the process developed in such a way that process errors are avoided or trapped before they result in product errors?
6)Robustness : Can the process carry on in spite of unexpected problems?
7)Maintainability: Can the process progress to reflect changing organizational requirements or identified process improvements?
8)Rapidity: How fast can the process of transferring a system from given specification be completed
It is impossible to optimize all process attributes simultaneously. If a rapid development process is needed then it may be necessary to decrease the process visibility, making a process visible means producing documents at regular intervals. This will slow down the process.
There are varieties of different general models or paradigms of software development:
1) The waterfall approach: This takes the above actions and represents them as separate process phase such as requirements specification, software design, implementation, testing and so on. After each stage is specified it is ‘signed off’ and development goes on to the following stage.
This is first explicit model of the software development process was derived from other engineering process. This was enthusiastically accepted by software project management. It offered a means of making the development process more visible. Because of cascade from one phase to another, this model is known as the ‘waterfall model’.
2) Evolutionary development: This approach interleaves the actions of specification, development and validation. An initial system is rapidly developed from very abstract definitions. This is then defined with customer input to produce a system which satisfies the customer’s need. The system may then be transported. Alternatively, it may be re-implemented using a more planned approach to produce a more robust and maintainable system.
Evolutionary development based on the idea of designing an initial implementation, exposing this to user comment and refining these through many versions until an adequate system has been developed. Rather than have separate specification, development and validation actions, these are carried out concurrently with rapid feedback across these activities.
3) Formal transformation: This approach is based on developing a formal mathematical system specification and transforming this specification, using mathematical methods to a program. These conversions are ‘correctness preserving’, this means that can be sure that the developed program meet its specification.
4) System assembly from reusable components: This technique supposes that parts of the system already exist. The system development process concentrates on integrating these parts rather than developing them from scratch.
The fist two of these approaches, namely waterfall approach and evolutionary development are now widely used for practical systems development. Some systems have been built using correctness-preserving transformations but this is still an experimental process.

By Ravi Kumar

PaluriPublished: 8/31/2004

Software Reuse

Software ReuseSoftware component reuse does not just indicate the reuse of application code. It is possible to reuse specification and designs. The potential gains from reusing abstract product of development process such as specifications may be grater than those from reusing code components. In most engineering disciplines the developed process is based on components reuse. Software system design usually consider that all component to be designed specially for the system being developed. There is no common base apart from libraries such as windows system libraries of reusable software components. By using widespread and systematic software reuse demands for lower software design and maintain costs along with increased quality can only be met.
Software components are not designed to one system but are tried and tested in a number of different environments. Design and implementations fault are discovered and removed so that reusable component contains few errors. It is impossible to achieve absolute reliability specification but reusable components may have an associated quality explanation. This permits users to integrate them with confidence in their systems.
Software component reuse does not just indicate the reuse of application code. It is possible to reuse specification and designs. The potential gains from reusing abstract product of development process such as specifications may be grater than those from reusing code components.
The reuse of software can be divided at a number of levels:
1)Application system reuse: It is possible to reuse the whole application system. The major problem here is to ensure that the software is portable. It should run on variety different platforms.
2)Sub-system reuse: It is possible to reuse major sub-systems of an application.
3)Module or object reuse: It is possible to reuse components of a system representing a collection of function.
4)Function reuse: It is possible to reuse software components, which implement a single function such as a mathematical function.
Application system reuse is widely used in software companies to implement their systems across a range of machines. Function reuse is widely used in standard libraries of reusable function such as graphics and mathematical libraries. Sub-system and module reuse are less usable.
Four aspects of software reuse are: 1)Software development with reuse: Software development with reuse is an approach which tries to maximize the reuse of existing software components. Benefit of this approach is that overall development costs of the software are decreased. Cost reduction is only one potential benefit of software reuse. Systematic reuse in the development offers further advantages: i)System reliability is increased: By using reused components in working systems should be more reliable than new components. These components have been tested in variety of operational systems environment and have therefore been exposed to realistic operating conditions.
ii)Overall process risk is reduced: If we use a function which is already exists, there is less uncertainty in the cost of reusing that component than in the costs of development. For project management this is important factor as it decreases uncertainty in project cost elimination. If relatively large components such as sub-stems are reused then this becomes true.
iii)Effective use can made of specialists : Application specialists doing the same work on different project environment instead these specialists can develop reusable components which encapsulate their knowledge.
iv)Organizational standards can be embodies in reusable components: We can reuse some standards such as user interface standard which can be implemented as a set of standard components.
v)Software development time can be reduced: It is necessary to bring a system to market as early as possible is more important than overall development costs. Reusing software components speeds up system production because both development and validation time should be reduced.
2)Software development for reuse: Component reuse may involve making different types of changes.
i)Name generalization: the component name should be modified so that they are neutral rather than a direct reflection of some specific application entity. ii)Operation generalization: This involves adding operations to a component or removing operation which are very specific to some application domain. iii)Exception generalization: This involves checking each component to see which exceptions it might throw and including these exceptions in the component interface.
3)Generator based reuse: An alternative way to reuse component is the generator view. In this approach reusable knowledge is confined in a program generator system which can be programmed in a domain oriented language.
High-level language compliers are most widely used ‘program generator’, where the reusable components are fragmented of object code corresponding to high level language construct. The reused elements are abstraction related to programming language statements. When a domain specific notation is used to describe the application, larger domain abstraction can be reused. Abstract approaches are: i)Application generator for business data processing: ii)Parser generator for language processing iii)Code generators in CASE tools
4)Application system reuse: A special case of software reuse is application system reuse where a whole application system is reused by a implementing it over a range of different computers and operating systems.
By Ravi Kumar
PaluriPublished: 9/5/2004