Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lectures_SSD2_Yermakova / Lectures_SSD2 Yermakova.doc
Скачиваний:
226
Добавлен:
25.02.2016
Размер:
3.16 Mб
Скачать

Define or Redefine the Problem

  1. Recognition of need: This might be generally recognized; it might come from marketing or management; it might originate in the technical groups; or it might come as a contract.

  2. Specification of requirements: This is a process of polling stakeholders as to what needs they have for a proposed software system. It is a good idea to make several iterations and to test assumptions with focus groups representing the actual users.

Plan a Solution to the Problem

  1. Enumeration of alternatives: Once requirements for a problem are in hand, enumerate known solutions. There usually will be more than one, each with implications for cooperating with existing systems, for ease of implementation (creation cost) and for maintenance (ongoing costs).

  2. System design, including tests: This is the actual technical design of a system once an alternative has been selected. It is critical to design tests of the system. It must be possible to recognize a working system unambiguously, and objectively.

Code the Solution

  1. Implementation of solution: Programmers code a system in the chosen language or languages. Decisions have been locked down at the design phase (for example, interfaces and performance) but details of how a piece of the system does what it must do are left to the programmer.

  2. Programmer testing of solution: First, the programmer examines software to see that it appears correct. At the next level, software teams meet to read and comment on each other's work in code review sessions. Whole system testing is conducted by project leaders.

  3. System acceptance: Another group of individuals operates the software for a period of time in simulated or real settings. System acceptance can be very formal or surprisingly informal.

Evaluate and Test Everything

  1. Test in context: Working systems will soon exhibit bugs that slipped past earlier filters. Also, design decisions will reveal their flaws at this stage. Really good systems often spark more demands for changes than bad ones: once people actually get the feel of using good software they get ideas about additional features they would like to have. Finally, the context in which a system operates may change, requiring revisions to the software. For example, a system is working perfectly for a small business, but introduction of the Internet requires the system to be integrated into the Web.

  2. Redesign: Now the redesign begins looping back to the first step of the process.

4.5.2 Open Source Model

Unless you work for Microsoft, you will not be allowed to read the source code for the Windows operating system (although Microsoft plans on offering an open source version of Windows). But, you can read the source code for the Linux operating system, make copies of it, even give it away for free. Linux is an example of an open source software project.

The open source approach is a convenient way for a large number of loosely organized programmers to contribute to the development of a piece of software. Usually they are unpaid volunteers who donate their time. They enjoy programming and have a need for that particular piece of software, so it is in their interest to help improve it by adding new features or fixing bugs. One person, or a small group, acts as the project coordinator and maintains the official version of the source. Other people suggest bug fixes, contribute new features, or improve the design of existing modules. The coordinators examine and test these contributions and decide how to integrate them into the current source.

Open source advocates argue that when code is available for anyone to read, "All bugs are shallow," meaning they will be tracked down quickly by somebody. In addition, some users place a greater degree of trust in open-source systems because it is harder to hide malicious features, such as built-in security holes or mechanisms that violate privacy. When you run a piece of software whose source code is not available for inspection, you must hope that the authors have not snuck in any undesirable behaviors. Sometimes they have.

Most software today is still produced using a closed-source model. Companies must invest substantial funds to create a successful software product. Giving the code away would rob them of the chance to recoup those costs through sales. The code may also contain what a company regards as proprietary technology, or trade secrets, such as tricks for improving the performance of a database system, that it does not want to reveal to competitors.

It is still possible to make money with open source software, by selling support services, printed manuals, or proprietary add-ons that enhance an open source product. Several companies now market Linux distributions this way. Another famous open source software system is the Firefox (formely Netscape) browser. Originally developed as a closed source product, Netscape decided to turn the browser into an open source system and give it away for free. The company makes money by selling server software and other services.