CS5391, course pack #6 Can Internet-based application(IBA) be engineered? IEEE software, September/October 1998, pp IEEE software, September/October 1998, pp Moderator: Roger S. Pressman Moderator: Roger S. Pressman Presented by: Wei Ding

Background A virtual roundtable was conducted over the Internet in June Participants: Software development leaders some of them are “old-line” software engineering proponents others focus solely on Internet-based software Moderator: Roger S. Pressman

1 st QUESTION “ Can Internet-based systems be engineered in the conventional sense of the term? If not, what makes them so different?” Some people think that any important product or system is worth engineering. That’s mean before starting to build them, it’s better to understand the problem, design a solution, implement them in a solid way, test it thoroughly, and have some mechanism for ensuring the quality. Many web developers think their world is really different and that conventional software engineering approaches simply don’t apply.

Differences The much shorter development times and product life cycles An IBA must be conceived, planned and produced in record time(days or months). The faster, new tools are needed Only the specific project’s indicated purpose need to be planned and designed.

Argument Not all parts of an IBA are produced in record time. Web pages are volatile and disposable The back-end databases are fairly stable and slow to change The top critical requirements and suitable architecture derived from engineering, cost, and other constraints. The system should be evolved and regularly measured against the last update of quantified requirements. Time-to-market and many other features of Web development are not unique to Web applications. The problem is fuzzy(unspecified), customers don’t know how to specify their requirement. We need an approach that allow for more freedom and flexibility as the project changes

Arguments(cont’) “Internet-based applications can not be engineering in the “conventional” sense, but then no system based on emerging technology can use the previous generation’s conventional engineering tools.”

2 nd Question: Speed Rules “How should we engineer systems that are often build by non-engineers, are dynamic, and must go live in days, not month?” Two schools of thought(Both is correct) One feels that the speed of development and new technology make web-based development different, therefore justifying a unique approach to building such systems The other believes that the need for solid engineering overshadows the “differences” in the technology being developed.

Advices 1 Seek existing solutions. Separate system from functionality as much as possible Use a development environment that lets you move fast. For example, using scripting languages, not C language.

Advices 2 State quality requirements quantitatively. Get contractual guarantees. Use proven track-record suppliers Build and expand the system in evolutionary stages. Consider appropriate systematic redundancy at many levels, to allow some degree of operation when failure occur.

The discussion about software testing The test-based approach to software quality take too long, and will be unacceptable in the Web-based future. Without testing, we couldn’t ensure what we’ve fixed is really fixed, and bugs are not reintroduced.

3 rd Question How should it organize teams of people to build software for the Internet when not all of them are “exceptional” “Them” – are members of development team “Exceptional” – some people with experience and motivation for new technology With any new software technology rapid growth, “exceptional people” do the work and produce high quality quickly. But as time passes, less competent people with lower motivation joined the team, there’s little doubt this will happen with Web-based software, as it has in every other software domain.

Understand The project manager admit They really don’t know the requirements They have to track social interaction The product will be late, so they have to pad estimates. There will be more bugs than anticipated, so they have to elevate testing to the higher level There will be personal turnover, so you have to constantly guard against hacks and inadequate documents.

Solution Learn to specify the critical requirements in a measurable and testable manner, and replace inadequate people, architectures or method by stronger ones. Reward developers with progress payments for real, relevant, measurable achievements. Keep task simple and team small. Break the task up into smaller pieces for subteams Decompose a task into cohesive pieces with thin interface. Powerful software tools of development are needed. Standards and engineering disciplines are needed. The exceptional skill is the ability to communicate with colleagues. Use the serious, complete documentation, modular design, planning for future updates, never consider the consequence of hiring “less qualified” people

The final words Engineering discipline is never a bad idea. The basic principles that lead to high-quality systems apply dynamic, great the web-based application Problem Applying the principles of solid software engineering isn’t the problem, the problem is in the overly dogmatic, bureaucratic application of the engineering process. But what’s dogmatic, bureaucratic, everyone has different understanding.