software eng
TRANSCRIPT
![Page 1: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/1.jpg)
![Page 2: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/2.jpg)
BooksAn Integrated Approach to Software
Engineering By Pankaj JaloteSoftware Engineering By Roger S. PressmanSoftware Engineering By Ian SommerwilleSoftware Engineering By Nasib Singh GillSoftware Engineering By K.K. Aggarwal
![Page 3: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/3.jpg)
SoftwareSoftware 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 toassure the quality of the software
![Page 4: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/4.jpg)
Difference between s/w and ProgramA 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
![Page 5: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/5.jpg)
Difference between s/w and ProgramA 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.
![Page 6: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/6.jpg)
Types of softwareThere 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
![Page 7: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/7.jpg)
Software ApplicationsSystem 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.
![Page 8: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/8.jpg)
Software ApplicationsEngineering 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.
![Page 9: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/9.jpg)
Software MythsSoftware is easy to changeTesting software can remove all the errorsReusing software increases safetySoftware can work right the first time.Software can be designed thoroughly enough
to avoid most integration problems.Software with more features is better
softwareAim is to develop working programs.
![Page 10: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/10.jpg)
Software CrisisThe 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 expensiveLate, costly and UnreliableProblem of change and rework
![Page 11: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/11.jpg)
Software EngineeringSoftware 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.
![Page 12: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/12.jpg)
Goals of Software EngineeringImprove the productivity of the developing processImprove the comprehension of the developed
software systemControlling and predicting the cost of software
developmentProducing what the customer wantsProducing software that satisfies specificationsProducing software systems with following
attributes :ReliabilityEfficiencyClarityExtensibility
![Page 13: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/13.jpg)
Goals of Software EngineeringProducing the following products in addition
to programs :DocumentationRequirement DocumentsDevelopment Plans
Improve the quality of the software product at all levels.
![Page 14: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/14.jpg)
Principles of Software EngineeringThese are the rules, which have to follow by software
development community ;Making quality as a primary.Give products to customers earlyDetermine the problem before writing the requirementsEvaluate design alternativesUse an appropriate process modelMinimize intellectual distancePut technique before toolsInspect codeGood management is more important than good
technologyTake responsibility
![Page 15: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/15.jpg)
Essential Characteristics of well-engineered software productSoftware 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.
![Page 16: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/16.jpg)
Essential Characteristics of well-engineered software productUsability : Software should have an appropriate user
interface and an adequate documentationOn 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
![Page 17: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/17.jpg)
Software ProcessAccording 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.
![Page 18: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/18.jpg)
Process ActivitiesSoftware 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.
![Page 19: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/19.jpg)
Process, Project and ProductsSoftware Process specifies a method of developing
softwareSoftware 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.
![Page 20: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/20.jpg)
Software processes
Project 1 Project i Project n
Product 1 Product 2 Product m
![Page 21: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/21.jpg)
Characteristics of a software ProcessOptimality : 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.
![Page 22: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/22.jpg)
![Page 23: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/23.jpg)
Characteristics of a software ProcessSupport 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.
![Page 24: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/24.jpg)
Characteristics of a software ProcessEarly 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.
![Page 25: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/25.jpg)
![Page 26: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/26.jpg)
Characteristics of a software ProcessProcess 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.
![Page 27: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/27.jpg)
Multiple processes A large software development company may
have multiple development processesA. For client-server based conventional applications
(sales processing, payroll)B. For enterprise-level (ERP) projects based on
packages and customizationC. For web-based e-commerce typeD. For data-warehousing/decision-support type
The company may have many projects in each category
![Page 28: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/28.jpg)
Software Process ModelA 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 ModelPrototypingIterative EnhancementSpiral Model
![Page 29: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/29.jpg)
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 takenE.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
![Page 30: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/30.jpg)
ReviewV&V
actions to be carried
out
(entry criteria) (exit criteria)
inputs
Project Control info
info for management
outputs
CONTROL
INPUT
Information to Management Process
OutputProcess Step
V&V
(entry criteria) (exit criteria)
![Page 31: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/31.jpg)
Water Fall ModelThe 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.
![Page 32: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/32.jpg)
Water Fall ModelOn 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.
![Page 33: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/33.jpg)
![Page 34: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/34.jpg)
Deliverables in Waterfall ModelRequirements document (SRS : Software
Requirement Specifications)Project plan System design documentDetailed design documentTest plans and test reportsSource codeSoftware manuals (user manual, installation
manual)Review reports
![Page 35: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/35.jpg)
Shortcomings of Waterfall ModelRequirements 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.
![Page 36: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/36.jpg)
PrototypingA 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.
![Page 37: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/37.jpg)
PrototypingPrototyping 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.
![Page 38: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/38.jpg)
PrototypingBased 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
![Page 39: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/39.jpg)
Prototyping
![Page 40: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/40.jpg)
Advantages of prototypeReduced 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.
![Page 41: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/41.jpg)
Disadvantages of prototypeInsufficient 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
![Page 42: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/42.jpg)
Iterative EnhancementIterative 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.
![Page 43: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/43.jpg)
Iterative EnhancementIn 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.
![Page 44: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/44.jpg)
Iterative EnhancementEach 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.
![Page 45: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/45.jpg)
![Page 46: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/46.jpg)
Spiral ModelThis 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.
![Page 47: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/47.jpg)
![Page 48: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/48.jpg)
Spiral ModelThe 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.
![Page 49: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/49.jpg)
Spiral Model DescriptionThe 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.
![Page 50: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/50.jpg)
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.
![Page 51: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/51.jpg)
Quadrant 2: Evaluate Alternatives, Identify, Resolve RisksEngineering 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.
![Page 52: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/52.jpg)
Quadrant 3: Develop, Verify, Next-Level ProductThe basic “waterfall” approach may be
employed—meaning concept of operations, design, development, integration, and test of the next system or product iteration.
![Page 53: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/53.jpg)
Quadrant 4: Plan Next PhasesThe 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
![Page 54: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/54.jpg)
Sofware Process 54
TimeboxingIterative is linear sequence of iterationsEach iteration is a mini waterfall – decide the
specs, then plan the iterationTime boxing – fix an iteration duration, then
determine the specsDivide iteration in a few equal stagesUse pipelining concepts to execute iterations
in parallel
![Page 55: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/55.jpg)
Sofware Process 55
Time Boxed IterationsGeneral 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
![Page 56: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/56.jpg)
Sofware Process 56
Time boxed IterationThis itself very useful in many situationsHas predictable delivery timesOverall product release and marketing can be
better plannedMakes time a non-negotiable parameter and
helps focus attention on schedulePrevents requirements bloatingOverall dev time is still unchanged
![Page 57: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/57.jpg)
Sofware Process 57
Timeboxing – Taking Time Boxed Iterations FurtherWhat if we have multiple iterations executing
in parallelCan reduce the average completion time by
exploiting parallelismFor parallel execution, can borrow pipelining
concepts from hardwareThis leads to Timeboxing Process Model
![Page 58: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/58.jpg)
Sofware Process 58
Timeboxing Model – BasicsDevelopment is done iteratively in fixed
duration time boxesEach time box divided in fixed stagesEach stage performs a clearly defined
task that can be done independentlyEach stage approximately equal in
durationThere is a dedicated team for each stageWhen one stage team finishes, it hands
over the project to the next team
![Page 59: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/59.jpg)
Sofware Process 59
TimeboxingWith this type of time boxes, can use
pipelining to reduce cycle timeLike hardware pipelining – view each
iteration as an instructionAs stages have dedicated teams,
simultaneous execution of different iterations is possible
![Page 60: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/60.jpg)
Sofware Process 60
ExampleAn iteration with three stages – Analysis,
Build, DeployThese stages are appx equal in many situationsCan adjust durations by determining the
boudaries suitablyCan adjust duration by adjusting the team size
for each stageHave separate teams for A, B, and D
![Page 61: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/61.jpg)
Sofware Process 61
Pipelined ExecutionAT starts executing it-1AT finishes, hands over it-1 to BT, starts
executing it-2AT 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)
…
![Page 62: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/62.jpg)
Sofware Process 62
Timeboxing Execution Software
Requirements Build Deploy
TB1
TB2
Requirements Build Deploy TB2
Requirements Build Deploy TB3
Requirements Build Deploy TB4
![Page 63: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/63.jpg)
Sofware Process 63
Timeboxing executionFirst iteration finishes at time TSecond finishes at T+T/3; third at T+2 T/3,
and so onIn steady state, delivery every T/3 timeIf T is 3 weeks, first delivery after 3 wks, 2nd
after 4 wks, 3rd after 5 wks,…In linear execution, delivery times will be 3
wks, 6 wks, 9 wks,…
![Page 64: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/64.jpg)
Sofware Process 64
Team SizeIn linear execution of iterations, the same
team performs all stagesIf each stage has a team of S, in linear
execution the team size is SIn 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
![Page 65: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/65.jpg)
Sofware Process 65
Team SizeMerely by increasing the team size we cannot
reduce cycle time - Brook’s lawTimeboxing allows structured way to add
manpower to reduce cycle timeNote that we cannot change the time of an
iteration – Brook’s law still holdsWork allocation different to allow larger team
to function properly
![Page 66: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/66.jpg)
Sofware Process 66
Work Allocation of Teams
Requirements Team
RequirementsAnalysis for TB1
RequirementsAnalysis for TB3
RequirementsAnalysis for TB2
RequirementsAnalysis for TB4
Build Team
Deployment Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3
Requirements Team
RequirementsAnalysis for TB1
RequirementsAnalysis for TB3
RequirementsAnalysis for TB2
RequirementsAnalysis for TB4
Build Team
Deployment Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3
![Page 67: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/67.jpg)
Sofware Process 67
TimeboxingAdvantages: Shortened delivery times, other
adv of iterative, distr. executionDisadvantages: 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
![Page 68: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/68.jpg)
Sofware Process 68
waterfallStrength Weakness Types of
Projects
SimpleEasy to executeIntuitive and logicalEasy contractually
All or nothing – too riskyReq frozen earlyMay chose outdated hardware/techDisallows changesNo feedback from usersEncourages req bloating
Well understood problems, short duration projects, automation of existing manual systems
![Page 69: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/69.jpg)
Sofware Process 69
PrototypingStrength Weakness Types of
Projects
Helps req elicitationReduces riskBetter and more stable final system
Front heavyPossibly higher cost and scheduleEncourages req bloatingDisallows later change
Systems with novice users; or areas with req uncertainity.Heavy reporting based systems can benefit from UI proto
![Page 70: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/70.jpg)
Sofware Process 70
IterativeStrength Weakness Types of
Projects
Regular deliveries, leading to biz benefitCan accommodate changes naturallyAllows user feedbackAvoids req bloatingNaturally prioritizes reqAllows reasonable exit pointsReduces risks
Overhead of planning each iterationTotal cost may increaseSystem arch and design may sufferRework may increase
For businesses where time is imp; risk of long projects cannot be taken; req not known and evolve with time
![Page 71: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/71.jpg)
Sofware Process 71
TimeboxingStrength Weakness Types of
Projects
All benefits of iterativePlanning for iterations somewhat easierVery short delivery times
PM becomes more complexTeam size is largerComplicated – lapses can lead to losses
Where very short delivery times are very importantWhere flexibility in grouping featuresArch is stable
![Page 72: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/72.jpg)
Software Project managementProper 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.
![Page 73: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/73.jpg)
Software management distinctionsThe product is intangibleThere are no standard software processes.Many software projects are 'one-off' projects.
![Page 74: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/74.jpg)
Management activitiesProposal writing.Project planning and scheduling.Project costing.Project monitoring and reviews.Personnel selection and evaluation.Report writing and presentations.
![Page 75: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/75.jpg)
Software RequirementsThe 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.
![Page 76: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/76.jpg)
Software RequirementsRegardless 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.
![Page 77: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/77.jpg)
Types of requirementUser 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
![Page 78: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/78.jpg)
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
User requirement definition
System requirements specification
![Page 79: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/79.jpg)
Client managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
Userrequirements
Systemrequirements
Software designspecification
![Page 80: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/80.jpg)
Functional and non-functional requirementsFunctional 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 requirementsThese are the constraints on the services or functions
offered by the system such as timing constraints, constraints on the development process, standards, etc.
Domain requirementsRequirements that come from the application domain of
the system and that reflect characteristics of that domain.
![Page 81: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/81.jpg)
Non-functional classificationsProduct requirements
Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirementsRequirements which are a consequence of organisational
policies and procedures e.g. process standards used, implementation requirements, etc.
External requirementsRequirements which arise from factors which are external
to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
![Page 82: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/82.jpg)
Requirements Engineering ActivitiesRequirements 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.
![Page 83: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/83.jpg)
Requirements Engineering ActivitiesRequirement 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.
![Page 84: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/84.jpg)
Software Requirement SpecificationThe 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.
![Page 85: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/85.jpg)
Need for SRSAn 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.
![Page 86: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/86.jpg)
Characteristics of SRSCorrect : 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.
![Page 87: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/87.jpg)
Characteristics of SRSConsistent : 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.
![Page 88: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/88.jpg)
Components of an SRSFunctionality : 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.
![Page 89: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/89.jpg)
Components of an SRSDesign 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
![Page 90: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/90.jpg)
What is not included in an SRS ?Project requirements
cost, delivery schedules, staffing, reporting procedures
Design solutionspartitioning of SW into modules, choosing data
structuresProduct assurance plans
Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures
![Page 91: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/91.jpg)
Uses of SRS DocumentProject 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.
![Page 92: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/92.jpg)
![Page 93: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/93.jpg)
PrototypeA 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.
![Page 94: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/94.jpg)
Uses of system prototypesRequirements 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.
![Page 95: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/95.jpg)
Prototyping benefitsMisunderstandings between software users
and developers are exposedMissing services may be detected and
confusing services may be identifiedA working system is available early in the
processThe prototype may serve as a basis for
deriving a system specificationThe system can support user training and
system testing
![Page 96: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/96.jpg)
Prototyping benefitsImproved system usabilityCloser match to the system neededImproved design qualityImproved maintainabilityReduced overall development effort
![Page 97: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/97.jpg)
Establishprototypeobjectives
Defineprototype
functionality
Developprototype
Evaluateprototype
Prototypingplan
Outlinedefinition
Executableprototype
Evaluationreport
![Page 98: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/98.jpg)
Prototyping in the software processEvolutionary 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 prototypingA 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
![Page 99: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/99.jpg)
Evolutionaryprototyping
Throw-awayPrototyping
Deliveredsystem
Executable Prototype +System Specification
OutlineRequirements
![Page 100: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/100.jpg)
Prototyping objectivesThe 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
![Page 101: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/101.jpg)
Evolutionary prototypingMust 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
![Page 102: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/102.jpg)
Build prototypesystem
Develop abstractspecification
Use prototypesystem
Deliversystem
Systemadequate?
YES
N
![Page 103: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/103.jpg)
Evolutionary prototyping advantagesAccelerated delivery of the system
Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability
User engagement with the systemNot only is the system more likely to meet user
requirements, they are more likely to commit to the use of the system
![Page 104: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/104.jpg)
Evolutionary prototypingSpecification, design and implementation are
inter-twinedThe system is developed as a series of
increments that are delivered to the customerTechniques for rapid system development are
used, such as CASE tools and 4GLsUser interfaces are usually developed using a
GUI development toolkit
![Page 105: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/105.jpg)
Evolutionary prototyping problemsManagement problems
Existing management processes assume a waterfall model of development
Specialist skills are required which may not be available in all development teams
Maintenance problemsContinual change tends to corrupt system
structure so long-term maintenance is expensive
Contractual problems
![Page 106: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/106.jpg)
Throw-away prototypingUsed to reduce requirements riskThe 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
![Page 107: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/107.jpg)
Outlinerequirements
Developprototype
Evaluateprototype
Specifysystem
Developsoftware
Validatesystem
Deliveredsoftwaresystem
Reusablecomponents
![Page 108: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/108.jpg)
Prototype deliveryDevelopers may be pressured to deliver a
throw-away prototype as a final systemThis is not recommended
It may be impossible to tune the prototype to meet non-functional requirements
The prototype is inevitably undocumentedThe system structure will be degraded through
changes made during developmentNormal organisational quality standards may
not have been applied
![Page 109: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/109.jpg)
Rapid prototyping techniquesVarious techniques may be used for rapid
developmentDynamic high-level language developmentDatabase programmingComponent and application assembly
These are not exclusive techniques - they are often used together
Visual programming is an inherent part of most prototype development systems
![Page 110: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/110.jpg)
Dynamic high-level languagesLanguages which include powerful data
management facilitiesNeed 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
![Page 111: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/111.jpg)
Prototyping LanguagesJava
Object-oriented, interactive
LISP AI-based
Visual BasicHTML+Javascript, HTML+Java
Web browser as graphical display
![Page 112: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/112.jpg)
Database programming languagesDomain 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 toolsetThe language + environment is sometimes
known as a fourth-generation language (4GL)Cost-effective for small- to medium-sized
business systems
![Page 113: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/113.jpg)
DBprogramming
language
Interfacegenerator Spreadsheet
Reportgenerator
Database management system
Fourth-generation language
![Page 114: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/114.jpg)
Component and application assemblyPrototypes 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
![Page 115: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/115.jpg)
Compound documentsFor some applications, a prototype can be
created by developing a compound documentThis 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
![Page 116: Software Eng](https://reader038.vdocuments.mx/reader038/viewer/2022102823/544e05efb1af9f6d2e8b4691/html5/thumbnails/116.jpg)
Compound document
Word processor Spreadsheet Audio player
Text 1 Text 2 Text 3
Text 4 Text 5
Table 1
Table 2
Sound 1
Sound 2