2. Books An Integrated Approach to Software Engineering By Pankaj Jalote Software Engineering By Roger S. Pressman Software Engineering By Ian Sommerwille Software Engineering By Nasib Singh Gill Software Engineering By K.K. Aggarwal

3. Software Software is Computer programs, procedures and possibly associated documentation and data pertaining to the operation of a computer system. The IEEE definition of software lists the following four components of software: Computer Program Procedures Documentation Data necessary for operating the software system All four components are needed in order to assure the quality of the software

4. Difference between s/w and Program A program is generally complete in itself and is generally used only by the author of the program. There is usually little documentation or other aids to help people use the program. Because the author is the user, the presence of :bugs” is not a major concern. Such programs are not designed with such issues as portability, reliability and usability in mind

5. Difference between s/w and Program A software, on the other hand, is used largely by people other than the developers of the system. The user may be from different background, so a proper user interface is provided. There is sufficient documentation to help these diverse users use the system. Programs are thoroughly tested before operational use. Because the product may be used in variety of environments, portability is a key issue. Much more effort and resources are required for a software product.

6. Types of software There are two types of Software Products : Generic Products : These are stand-alone systems which are produced by the development organizations and sold on the open market to any customer who is able to buy them. Example: Database, word processor, drawing package. Bespoke (or customized products) : These soft wares are specially developed according to the customer requirements. Example : system written to support a particular business process, air traffic control system

7. Software Applications System Software : System software is a collection of programs written to service other programs. Example : operating system, compiler, editor, drivers etc. Real-Time Software : Programs that monitor/analyze/control real world events as they occur are called real-time softwares. A real-time system must respond within strict time constraints. Business Software : Applications in this area restructure existing data in a way that facilitates business operations or management decision making. Example: Payroll, inventory etc.

8. Software Applications Engineering and Scientific Software : Engineering and scientific software has been characterized by “number crunching” algorithm. Example : Computer-aided design, system simulation, astronomy etc. Embedded Software : Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Example : microwave oven etc.

9. Software Myths Software is easy to change Testing software can remove all the errors Reusing software increases safety Software can work right the first time. Software can be designed thoroughly enough to avoid most integration problems. Software with more features is better software Aim is to develop working programs.

10. Software Crisis The problems associated with software development are characterized as software crisis. In other words, the software crisis is characterized by an inability to develop software on time, on budget and within requirements. Software Problems : Software is expensive Late, costly and Unreliable Problem of change and rework

11. Software Engineering Software Engineering is a discipline whose aim is the production of fault-free software that satisfies the user’s needs and that is delivered on time and within budget. Software Engineering is the systematic development, operation, maintenance and retirement of the software. IEEE Definition : Software Engineering is the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software.

12. Goals of Software Engineering Improve the productivity of the developing process Improve the comprehension of the developed software system Controlling and predicting the cost of software development Producing what the customer wants Producing software that satisfies specifications Producing software systems with following attributes : Reliability Efficiency Clarity Extensibility

13. Goals of Software Engineering Producing the following products in addition to programs : Documentation Requirement Documents Development Plans Improve the quality of the software product at all levels.

14. Principles of Software Engineering These are the rules, which have to follow by software development community ; Making quality as a primary. Give products to customers early Determine the problem before writing the requirements Evaluate design alternatives Use an appropriate process model Minimize intellectual distance Put technique before tools Inspect code Good management is more important than good technology Take responsibility

15. Essential Characteristics of well-engineered software product Software engineering is not just about producing software products but involves producing software product in a cost-effective manner. Efficiency : Software should not make wasteful use of system resources such as memory and processor cycles. Maintainability : It should be possible to evolve software to meet the changing requirements of the customers. Dependability : It is the ability of the software that should not cause any physical or economic damage in the event of the system failure.

16. Essential Characteristics of well-engineered software product Usability : Software should have an appropriate user interface and an adequate documentation On time : Software should be developed well in time. Within budget : The software development costs should not overrun and it should be within budgetary limits. Functionality : The software system should exhibit proper functionality. Adaptability : The software system should have the ability of getting adopted to a reasonable extent with the changing requirement

17. Software Process According to Webster, the process means “a particular method of doing something, generally involving a number of steps or operation”. Software process refers to the method of developing software. Definition : A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. The desired result is high-quality software at low cost.

18. Process Activities Software specification : The functionality of the software and constraints on its operation must be defined. Software development : 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. Different software processes organize these activities in different ways are described at different levels of details.

19. Process, Project and Products Software Process specifies a method of developing software Software Project is a development project in which software process is used. Software Products are the outcome of a software project. A software process specifies the abstract set of activities that should be performed to go from user needs to final product. The actual act of executing the activities for some specific user needs is a software project. And all the outputs that are produced while the activities are being executed are the products.

20. Process, Project and Products Software processes Project 1Project iProject n Product 1Product 2Product m

21. Characteristics of a software Process Optimality : Optimality means that the process should be able to produce high-quality software at low cost. Scalability : Scalability means that it should also be applicable for large software projects. Predictability : Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed. A predictable process is said to be under statistical control. A process is under statistical control if following the same process produces similar results.

22. Process under statistical control

23. Characteristics of a software Process Support Testability and Maintainability : The goal of the process should not be to reduce the effort of design and coding, but to reduce the cost of testing and maintenance because testing and maintenance require more effort as compared to coding.

24. Characteristics of a software Process Early Defect Removal and Defect Prevention : Software process should attempt to detect errors that occur in a phase during that phase itself and should not wait until testing to detect errors. The greater the delay in detecting an error after it occurs, the more expensive it is to correct it. An error that occurs during the requirements phase, if corrected during acceptance testing, can cost up to 100 times more than correcting the error during the requirement phase itself. Even better is to provide support for defect prevention. This requires that the process of performing the activities should be such that fewer defects are introduced.

25. Cost of correcting errors

26. Characteristics of a software Process Process Improvement : Having process improvement as a basic goal of the software process implies that the software process used is such that it supports its improvement. This requires that there be means for evaluating the existing process and understanding the weakness in the process. Only when support for these activities is available can process improvement be undertaken.

27. Multiple processes A large software development company may have multiple development processes A. For client-server based conventional applications (sales processing, payroll) B. For enterprise-level (ERP) projects based on packages and customization C. For web-based e-commerce type D. For data-warehousing/decision-support type The company may have many projects in each category

28. Software Process Model A Development process model specifies some activities that, according to the model, should be performed and the order in which they should be performed. The 4 basic software process models are used : Waterfall Model Prototyping Iterative Enhancement Spiral Model

29. Process step … A production process is a sequence of steps. Each step performs a well-defined activity leading toward the satisfaction of the project goal, with the output of one step forming the input of the next one. Step must be executed as per project plan that gives duration, effort, resources, constraints, etc. It must produce information for management so that corrective actions can be taken E.g., adding more resources A step ends in a review (V&V) Verification: check consistency of outputs with inputs (of the step) Validation: check consistency with user needs

30. Process step Review V&V actions to be carried out (entry criteria) (exit criteria) inputs Project Control info info for management outputs CONTROL INPUT Information to Management Process Output Process Step V&V (entry criteria)(exit criteria)

31. Water Fall Model The Waterfall life model was introduced by Winston Royce in 1970. The simplest process model is waterfall model, which states that the phases are organized in a linear order. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements 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 done.

32. Water Fall Model On successful completion of testing, the system is installed. After this, the regular operation and maintenance of the system takes place. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and the beginning of the next, some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation means that will ensure that the output of a phase is consistent with its input and that the output of the phase is consistent with the overall requirements of the system.

34. Deliverables in Waterfall Model Requirements document (SRS : Software Requirement Specifications) Project plan System design document Detailed design document Test plans and test reports Source code Software manuals (user manual, installation manual) Review reports

35. Shortcomings of Waterfall Model Requirements may not be clearly known, especially for applications not having existing (manual) counterpart. Requirements change with time during project life cycle itself The hardware technology will become obsolete Considered documentation-heavy: so much documentation may not be required for all types of projects.

36. Prototyping A prototype is a working model that is functionally equivalent to a component of the product. The basic idea in prototyping is that instead of freezing the requirements before any design or coding can proceed, a throwaway prototype is built to help understand the requirements. Development of the prototype undergoes design, coding and testing but each of these phases is not done very thoroughly. By using this prototype, the client can get an actual feel of the system. This results in more stable requirements that change less frequently.

37. Prototyping Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determine the requirements. A development process using throwaway prototyping proceeds as follows. The development of the prototype typically starts when the preliminary version of the requirements specification document has been developed. After the prototype has been developed, the end users and clients are given an opportunity to use the prototype and play with it.

38. Prototyping Based on the feedback, the prototype is modified to incorporate some of the suggested changes that can be done easily and then the users and clients are again allowed to use the system. This cycle repeats until, in the judgment of the prototypers and analysts, the benefit from further changing the system outweighed by the cost and time involved in making the changes. Only those features are included in the prototype that will have a valuable return from the user experience. Development approach is quick and dirty with focus on quick development rather than quality

39. Prototyping

40. Advantages of prototype Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.

41. Disadvantages of prototype Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system. Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex

42. Iterative Enhancement Iterative Enhancement tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.

43. Iterative Enhancement In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.

44. Iterative Enhancement Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available.

45. Iterative Enhancement

46. Spiral Model This is a recent model that has been proposed by Boehm. As the name suggests, the activities in this model can be organized like a spiral. The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints.

48. Spiral Model The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and constraints. This will also involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities such as benchmarking, simulation and prototyping. Next, the software is developed by keeping in mind the risks. Finally the next stage is planned.

49. Spiral Model Description The development spiral consists of four quadrants Quadrant 1: Determine objectives, alternatives, and constraints. Quadrant 2: Evaluate alternatives, identify, resolve risks. Quadrant 3: Develop, verify, next-level product. Quadrant 4: Plan next phases.

50. Quadrant 1: Determine Objectives, Alternatives, and Constraints Activities performed in this quadrant include: Establish an understanding of the system or product objectives—namely performance, functionality, and ability to accommodate change. Investigate implementation alternatives—namely design, reuse, procure, modify Investigate constraints imposed on the alternatives— namely technology, cost, schedule, support, and risk. Once the system or product’s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

51. Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions.

52. Quadrant 3: Develop, Verify, Next-Level Product The basic “waterfall” approach may be employed— meaning concept of operations, design, development, integration, and test of the next system or product iteration.

53. Quadrant 4: Plan Next Phases The spiral development model has one characteristic that is common to all models—the need for advanced technical planning and multidisciplinary reviews at critical staging or control points

54. Sofware Process54 Timeboxing Iterative is linear sequence of iterations Each iteration is a mini waterfall – decide the specs, then plan the iteration Time boxing – fix an iteration duration, then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel

55. Sofware Process55 Time Boxed Iterations General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it Completion time is fixed, the functionality to be delivered is flexible

56. Sofware Process56 Time boxed Iteration This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall dev time is still unchanged

57. Sofware Process57 Timeboxing – Taking Time Boxed Iterations Further What if we have multiple iterations executing in parallel Can reduce the average completion time by exploiting parallelism For parallel execution, can borrow pipelining concepts from hardware This leads to Timeboxing Process Model

58. Sofware Process58 Timeboxing Model – Basics Development is done iteratively in fixed duration time boxes Each time box divided in fixed stages Each stage performs a clearly defined task that can be done independently Each stage approximately equal in duration There is a dedicated team for each stage When one stage team finishes, it hands over the project to the next team

59. Sofware Process59 Timeboxing With this type of time boxes, can use pipelining to reduce cycle time Like hardware pipelining – view each iteration as an instruction As stages have dedicated teams, simultaneous execution of different iterations is possible

60. Sofware Process60 Example An iteration with three stages – Analysis, Build, Deploy These stages are appx equal in many situations Can adjust durations by determining the boudaries suitably Can adjust duration by adjusting the team size for each stage Have separate teams for A, B, and D

61. Sofware Process61 Pipelined Execution AT starts executing it-1 AT finishes, hands over it-1 to BT, starts executing it-2 AT finishes it-2, hands over to BT; BT finishes it-1, hands over to DT; AT starts it-3, BT starts it-2 (and DT, it-1) …

62. Sofware Process62 Timeboxing Execution

63. Sofware Process63 Timeboxing execution First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3, and so on In steady state, delivery every T/3 time If T is 3 weeks, first delivery after 3 wks, 2 nd after 4 wks, 3 rd after 5 wks,… In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,…

64. Sofware Process64 Team Size In linear execution of iterations, the same team performs all stages If each stage has a team of S, in linear execution the team size is S In pipelined execution, the team size is three times (one for each stage) I.e. the total team size in timeboxing is larger; and this reduces cycle time

65. Sofware Process65 Team Size Merely by increasing the team size we cannot reduce cycle time - Brook’s law Timeboxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration – Brook’s law still holds Work allocation different to allow larger team to function properly

66. Sofware Process66 Work Allocation of Teams

67. Sofware Process67 Timeboxing Advantages: Shortened delivery times, other adv of iterative, distr. execution Disadvantages: Larger teams, proj mgmt is harder, high synchronization needed, CM is harder Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping

68. Sofware Process68 waterfall StrengthWeaknessTypes of Projects Simple Easy to execute Intuitive and logical Easy contractually All or nothing – too risky Req frozen early May chose outdated hardware/tech Disallows changes No feedback from users Encourages req bloating Well understood problems, short duration projects, automation of existing manual systems

69. Sofware Process69 Prototyping StrengthWeaknessTypes of Projects Helps req elicitation Reduces risk Better and more stable final system Front heavy Possibly higher cost and schedule Encourages req bloating Disallows later change Systems with novice users; or areas with req uncertainity. Heavy reporting based systems can benefit from UI proto

70. Sofware Process70 Iterative StrengthWeaknessTypes of Projects Regular deliveries, leading to biz benefit Can accommodate changes naturally Allows user feedback Avoids req bloating Naturally prioritizes req Allows reasonable exit points Reduces risks Overhead of planning each iteration Total cost may increase System arch and design may suffer Rework may increase For businesses where time is imp; risk of long projects cannot be taken; req not known and evolve with time

71. Sofware Process71 Timeboxing StrengthWeaknessTypes of Projects All benefits of iterative Planning for iterations somewhat easier Very short delivery times PM becomes more complex Team size is larger Complicated – lapses can lead to losses Where very short delivery times are very important Where flexibility in grouping features Arch is stable

72. Software Project management Proper management is an integral part of software development. A large software development project involves many people working for a long period of time. We have seen that a development process typically partition the problem of developing software into a set of phases. To meet the cost, quality and schedule objectives, resources have to be properly allocated to each activity for the project, and progress of different activities has to be monitored and corrective actions taken, if needed. All these activities are part of the project management process. The focus of the management process is on issues like planning a project, estimating resources and schedule and monitoring and controlling the project.

73. Software management distinctions The product is intangible There are no standard software processes. Many software projects are 'one-off' projects.

74. Management activities Proposal writing. Project planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations.

75. Software Requirements The description of the services and constraint s are the requirements for the system and the process of finding out, analyzing, documenting and checking these services and constraints is called requirement engineering. Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capability that the system, which is yet to be developed, should have. It is because we are dealing with specifying a system that does not exist in any form, that the problem of requirements becomes complicated.

76. Software Requirements Regardless of how the requirements phase proceeds, it ultimately ends with the software Requirement Specification (SRS). SRS is a document that completely describes what the proposed system should do without describing how to do.

77. Types of requirement User requirements Statements in natural language (NL) plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

78. Definitions and specifications

79. Requirements readers

80. Functional and non-functional requirements Functional requirements These are the statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do. Non-functional requirements These are the constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain.

81. Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

82. Requirements Engineering Activities Requirements Elicitation : Requirements elicitation is the activity during which software requirements are discovered, articulated and revealed from stakeholders. Requirement Analysis : Requirement Analysis is the activity during which the requirements gathered during elicitation are analyzed for conflicts, ambiguity, inconsistencies or missing requirements. Requirement Specification : Requirement specification is the activity during which requirements are recorded in one or more forms, usually is a Software Requirement Specification Document.

83. Requirements Engineering Activities Requirement validation : Requirement validation is the activity during which the requirements are checked for omitted, extra, ambiguous and inconsistent requirements. Requirement management : Requirement Management involves establishing and maintaining an agreement with the customer on the requirements for the software project.

84. Software Requirement Specification The SRS is a document that completely describes what the proposed software should do without describing how the software will do it. It can be a written document, a graphical model, a formal mathematical model, a prototype or any combination of these. Some suggest that a standard template should be developed and used for a system specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner.

85. Need for SRS An SRS establishes the basis for agreement between the client and the supplier on what the software product will do. An SRS provides a reference for validation for the final product A high quality SRS is a prerequisite to high quality software. A high-quality SRS reduces the development cost.

86. Characteristics of SRS Correct : A SRS is correct if every requirement included in the SRS represents something required in the final system. Complete : An SRS is complete if everything the software supposed to do is specified in the SRS. Unambiguous : An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Verifiable : A requirement is variable if there exist some cost effective process that can check whether the final software meets that requirements.

87. Characteristics of SRS Consistent : An SRS is consistent if there is no requirement that conflict with another. Modifiable : An SRS is modifiable if its structure and style are such that any necessary changes can be made easily while preserving completeness and consistency.

88. Components of an SRS Functionality : Functional requirements specify which output should be produced from the given inputs. Performance : All the requirements relating to the performance characteristics of the system must be clearly specified. 2 types of performance requirements : Static requirements are those that do not impose constraint on the execution characteristics of the system. Dynamic requirements specify constraints on the execution behavior of the system.

89. Components of an SRS Design constraints on an implementation : There are a number of factors in the client’s environment that may restrict the choices of a designer. Such factors include standards that must be followed. Standard Compliance : Standards may include the report format and accounting procedures. Hardware Limitations : The software nay have to operate on some existing hardware, thus imposing restrictions on the design. Reliability and fault tolerance : Requirements about system behavior in the face of certain kinds of faults is specified. External interfaces

90. What is not included in an SRS ? Project requirements cost, delivery schedules, staffing, reporting procedures Design solutions partitioning of SW into modules, choosing data structures Product assurance plans Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures

91. Uses of SRS Document Project managers base their plans and estimates of schedule, effort and resources on it. Development team needs it to develop product. The testing group needs it to generate test plans based on the described external behavior. The maintenance and product support staff need it to understand what the software product is supposed to do. The publications group writes documentation, manuals etc from it. Customers rely on it to know what product they can expect.

92. Format of SRS (IEEE Standard)

93. Prototype A prototype is an initial version of a software system which is used to demonstrate concepts, try out design options and generally to find out more about the problem and its possible solution. Rapid development of the prototype is essential so that costs are controlled and users can experiment with the prototype early in the software process. Prototyping can be used as a risk analysis and reduction technique. A significant risk in software development is requirements errors and omissions.

94. Uses of system prototypes Requirements elicitation : Users can experiment with a prototype to see how the system supports their work Requirements validation : The prototype can reveal errors and omissions in the requirements Experiments have shown that prototyping reduces the number of problems with the requirements specifications. Furthermore, the overall development costs may be lower if a prototype is developed.

95. Prototyping benefits Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing

96. Prototyping benefits Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort

97. Prototyping process

98. Prototyping in the software process Evolutionary prototyping An approach to system development where an initial prototype is produced and refined through a number of stages to the final system Throw-away prototyping A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process

99. Approaches to prototyping

100. Prototyping objectives The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood

101. Evolutionary prototyping Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems Based on techniques which allow rapid system iterations Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

102. Evolutionary prototyping

103. Evolutionary prototyping advantages Accelerated delivery of the system Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability User engagement with the system Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

104. Evolutionary prototyping Specification, design and implementation are inter- twined The system is developed as a series of increments that are delivered to the customer Techniques for rapid system development are used, such as CASE tools and 4GLs User interfaces are usually developed using a GUI development toolkit

105. Evolutionary prototyping problems Management problems Existing management processes assume a waterfall model of development Specialist skills are required which may not be available in all development teams Maintenance problems Continual change tends to corrupt system structure so long-term maintenance is expensive Contractual problems

106. Throw-away prototyping Used to reduce requirements risk The prototype is developed from an initial specification, delivered for experiment then discarded The throw-away prototype should not be considered as a final system as some system characteristics may have been left out

107. Throw-away prototyping

108. Prototype delivery Developers may be pressured to deliver a throw-away prototype as a final system This is not recommended It may be impossible to tune the prototype to meet non- functional requirements The prototype is inevitably undocumented The system structure will be degraded through changes made during development Normal organisational quality standards may not have been applied

109. Rapid prototyping techniques Various techniques may be used for rapid development Dynamic high-level language development Database programming Component and application assembly These are not exclusive techniques - they are often used together Visual programming is an inherent part of most prototype development systems

110. Dynamic high-level languages Languages which include powerful data management facilities Need a large run-time support system. Not normally used for large system development. (Less of a problem nowadays) Some languages offer excellent UI development facilities

111. Prototyping Languages Java Object-oriented, interactive LISP AI-based Visual Basic HTML+Javascript, HTML+Java Web browser as graphical display

112. Database programming languages Domain specific languages for business systems based around a database management system Normally include a database query language, a screen generator, a report generator and a spreadsheet. May be integrated with a CASE toolset The language + environment is sometimes known as a fourth-generation language (4GL) Cost-effective for small- to medium-sized business systems

113. Database programming

114. Component and application assembly Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together The composition mechanism must include control facilities and a mechanism for component communication The system specification must take into account the availability and functionality of existing components

115. Compound documents For some applications, a prototype can be created by developing a compound document This is a document with active elements (such as a spreadsheet) that allow user computations Each active element has an associated application which is invoked when that element is selected The document itself is the integrator for the different applications

116. Application linking in compound documents