BCA-SE

Software Engineering

Software Problem:

                   A program to solve a problem and a programming system product to solve the same problem are two entirely different things. Obviously much more effort and resources are required for a programming system product. Brooks estimates that as a rule of thumbs, a programming system product costs approximately ten times as much as a corresponding program. The industry is largely interested in developing programming systems products and commercial software system or packages fall in this category. The programming systems product is also sometimes called production or industrial quality software. There are following problem in a software creation:

Software is Expensive:

                                The cost of hardware has consistently decreased and the cost of software is increased. As a result, the HW/SW ratio for a computer system has shown a reversal from the early years.

The main reason for the high cost of software is that software development is still labor intensive. To get an absolute idea of the costs involved, let us consider the current state of practice in the industry. A Dilivered line of code (DLOC) is by far the most commonly used measure of software size in the industry. As the main cost of producing software is in the manpower employed, the cost of developing software is generally measured in terms of person-months of effort spent in development. And productivity is frequently measured in the industry in terms of DLOC per person month.

Late, Costly and Unreliable:

                                                The software industry has gained a reputation of not delivering software within schedule and budget and of producing software systems of poor quality. There are numerous instances of projects that enforce this view. In fact, a whole column in software engineering notes is dedicated to such instances. It is clear that cost and schedule overruns and the problem of reliability are major contributors to the software crisis.

                            Software failures are different from failures of hardware. Because in the hardware, there is a problem of aging. It means after a fixed date it is expired. On the other hand a software product never wears out due to age. It is out due to errors.

Problem of change and rework:

                             Once the software is delivered and deployed, it enters the maintenance phase. All systems need maintenance, but for other systems it is largely due to problems that are introduced due to aging. Software needs to be maintained not because some of its component wear out and need to be replaced, but because there are often some residual errors remaining in the system that must be removed as they are discovered.

                       These errors once discovered, need to be removed, leading to the software getting changed. This is sometimes called corrective maintenance. Even without bugs, software frequently undergoes change. Hence, the software must adapt to the needs to change environment. The changed software then changes the environment, which in turns requires further change. This phenomenon is sometimes called the law of software evolution. Maintenance due to this phenomenon is sometimes called adaptive maintenance.

Software Engineering Problem:

                             A primary reason for this is that approaches to software development are frequently ad hoc and programming-centered. The ad hoc and programming-centered approach may work for small projects, but for problem domain that we are interested in, these approaches generally do not work. If we have to control this software crisis, some mathematical approach is need for software development. This is where software engineering comes in.

"Software engineering is the systematic approach to the development operation, maintenance and retirement of software."

There are some problems in software engineering:

 The problem of scale:

                      A fundamental problem of software engineering is the problem of scale; development of very large system requires a very different set of methods compared to developing a small system. Methods that one can use to develop programs of a few hundred lines cannot be expected to work when software of a hundred thousand lines needs to be developed. A different set of methods have to be used for developing large software. According to COCOMO model, a project is small if its size in thousands of delivered lines of code is 2KDLOC, intermediate if the size is 8 KDLOC, medium if the size is 32 KDLOC and large if the size is 128 KDLOC.

  Cost and schedule:

                   The cost of developing a system is the cost of the resources used for the system like manpower, hardware, software and other support resources. Generally the software development is largely labor intensive. The cost of software projects are measured in terms of person-months

              Schedule is an important factor in many projects. In the business trends, the time to market of a product should be reduced; that is, the cycle time from concept to delivery should be small.

Quality:
            One of the major factors driving any production discipline is quality. Clearly, developing methods that can produce high quality software is another fundamental goal of software engineering. We can view quality of a software product as having three dimensions:

•  Product Operation
•  Product Transition
•  Product Revision

Product operations, deal with quality factors such as correctness, reliability and efficiency. Product transition deals with quality factors like portability and interportability. Product Revision is concerned such as maintainability and testability.

  The problem of consistency:

                            Through high quality and low cost and small cycle time are the primary objective of any project, for an organization there is another goal: consistency. An organization involved in a software development does not just want low cost and high quality for a project, but it wants these consistently. Achieving consistency is an important problem that software engineering has to tackle.

The Software Engineering Approach:

                                                                Develop methods and procedures for software development that can scale up for large systems and that can be used to consistently produce high quality software at low cost and with a small cycle time. That is, the key objectives are consistency, low cost, high quality, small cycle time and scalability. The basic approach that software engineering takes is to separate the development process from the developed product. There are some approaches that resolve the software engineering problem. These approaches are shown below:

1.      Phased Development Process:

                                              A development process consist of various phases, each phase ending with a defined output. The phase is performed in an order specified by process model being folowed. The main reason for having a phased process is that it breaks the problem of developing software into successfully performing a set of phases, each handling a different concern of software development. The phases of software are given below:

a)      Requirements Analysis:

                 This phase is done in order to understand the problem of the software system is to solve. The problem could be automating an existing manual process, developing a new automated system or a combination of the two. In this phase we analyze the user what should he want. The emphasis in requirements analysis is on identifying what is need from the system, not how the system achieves this goal. This task is completed by the fact that there are often at least two parties involved in software development- a client and a developer.

b)      Software Design;

                  The purpose of the design phase is to plan a solution of the problem specified by the requirements document. This phase is the first step in moving from the problem domain to the solution domain. The design of a system is perhaps the most critical factor affecting the quality of the software; it has a major impact on later phases, particularly testing and maintenance. The output of this phase is the design document.

c)       Coding:

                  Once the design is complete, most of the major decisions about the system have been made. However, many of the details about coding the design, which often depend on the programming language chosen, are not specified during design. The goal of the coding phase is to translate the design of the system into code in a given programming language.

d)      Testing:

            Testing is the major quality control measure used during software development. Its basic function is to detect errors in the software. During requirements analysis and design, the output is a document that is usually textual and non executable. After the coding phase, computer programs are available that can be executed for testing purpose. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phase. Thus the goal of testing is to uncover requirement, design and coding errors in the programs.

2.       Project Management and Metrics:

                                      A phased development process is central to the software engineering approach. However, a development process does not specify how to allocate resources to the different activities in the process. All project management activities require information, upon which the management decisions are based. Hence, for effective project management, objective data is needed. For this, software metrics are used.

                                                Software metrics are quantifiable measures that could be used to measure different characteristics of a system or the software development process. There are two types of metrics used for software development: product metrics and process metrics. Product metrics are used to quantify characteristics of the product being developed. Process metrics are used to quantify characteristics of the process being used to develop the software.

Waterfall Model:

                             The simplest process model is the waterfall model, which states that phases are organized in a linear order. The waterfall model, sometimes called the classic life cycle model suggests a systematic, sequential approach to software development. This model is named “Waterfall Model”, because its  diagrammatic representation resembles waterfall. With the water fall model the sequence of activites performed in software development project : requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing.

In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirement analysis and project planning begins. The design starts after the requirements analysis is complete and coding begins after the design is complete. Once the programming is completed, the code is integrated and testing is done. On successful completion of testing, the system is installed. After this, the regular operation and maintenance of the system takes place.

·         For successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway.

·         Any different ordering of the phases will result in a less successful software product.

A successful software product is one that satisfies all the objectives of development project. These objectives include satisfying the requirement and performing the development with in time and cost constraints. Generally for reasonable size product, all the phases listed in the model must be performed explicitly and formally. Informally performing the phases will work only for very small projects.

Projects Output in Waterfall Model:

There are a number of intermediate outputs that must be produced to produce a successful product. Through the set of documents, that should be produced in a project is dependent on how the process is implemented, the following is a set of documents that generally forms the minimum set that should be produced in each project.

·         Requirements document

·         Project plan

·         System design document

·         Detailed design document

·         Test plan and test reports

·         Final code

·         Software manuals

·         Review reports

Expect for the last one, these are the outputs of the phases. Review are necessary, especially for the requirements and design phases, because other certification means are frequently not available.

Limitation of  the waterfall model:

1.      The waterfall model assumes that the requirements of a system can be frozen before the design begins.

2.      Freezing the requirements usually requires choosing the hardqare.

3.      The waterfall model usually stipulates that the requirements be completely specified before the rest of the development can proceed.

4.      It is a document drive that requires fromal documents at the end of each phase.

Prototype model:

The goal of a prototyping- based development process is to counter the first two limitations of the waterfall model. The basic idea here is that instead of freezing the requirements before any design or coding can proceed, a throughway prototype is built to help understand the requirements. The prototype is developed based on the currently known requirements. By using this prototype, the client can get an actual feel of the system, because the interaction with the prototype can enable the client to better understand the requirements of the desired system.

                                                           Prototype is catching on. It is well suited for projects where requirements are hard to determine and the confidence in obtained requirements is low in such project a waterfall model will have to freeze the requirements in order for the development to continue, even when the requirements are not stable. This leads to requirements changes and associated rework while the development is going on. Overall, in projects where requirements are not properly understood in the beginning, using the prototyping process model can be the most effective method fro developing the software. It is an excellent technique for reducing some types of risks associated with a project.  

Spiral Model

This is a recent model that has been proposed by Boehm[Boe88]. As the name suggests, the activities in this model can be organized like a spiral that has many cycles. Each cycle in the spiral begins with the identification of objectives for that cycle, the different alternatives that are possible for achieving the objectives, and the constraints that exist. This is the first quadrant of the cycle(upper-left quadrant). The next step in the cycle is to evaluate these different alternatives based on the objectives and constraints. The focus of evolution in this step is based on the risk preception for the project. Risks reflect the chances that some of the objectives of the project may not be met. The next step is to develop strategies that resolve the uncertainties and risk. This step may involve activities such as benchmark, simulation and prototyping. Next the software is developed, keeping in mind the risk. Finally  the next stage is planned.

            An important feature of the model is that each cycle of the spiral is completed by review that covers all the products developed during that cycle, including plans for the next cycle. The spiral model works for development as well as enhancement projects.