Lectures 1A and 1B
Upcoming SlideShare
Loading in...5
×
 

Lectures 1A and 1B

on

  • 416 views

 

Statistics

Views

Total Views
416
Views on SlideShare
416
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • You should have the course outline in front of you. The CSSE office has a master copy available for photocopying. I will now go over the important points.
  • Submission of Assignments Students are required to submit their assignment by 12 NOON on the due date. Shortly thereafter, the box will be emptied and sealed. Late assignments must be handed directly to staff in the Enquiries Office, where they will be stamped with the date and time received. Late submissions will be penalised at the following rate: Submission on the due date but after 12 noon: -10% Submission the day after the due date -20% Submission two days after the due date: -40% Submission 3 or more days after the due date will not be accepted. Extensions Extensions will not be given for group assignments. Given the size of the groups, the illness of individual students will not be accepted as a reason for extensions. In the case of extensions for individual work, extensions will be granted if valid medical certificates are produced. Group Assignments All members of the group will rate all other members of the group and this rating will modify the mark that each individual receives. If a group is having trouble with an individual member and your efforts to resolve the issue has been fruitless, then the group should approach myself to assist in resolving the problem prior to submission of the assignment.
  • See http://wwwsel.iit.nrc.ca/sedefn/SEdefn.html
  • See http://wwwsel.iit.nrc.ca/sedefn/SEdefn.html
  • CS90 - How Westpac wasted $250 million - In 1989 Westpac decided to replace their entire banking system, using lots of cutting edge technology (OO etc.). ~2000 programmers worked on the system. About 1993, when the banks all ran into trouble, a new manager was brought in. The new manager asked for the projected delivery date - and was told ~2040. The project was scrapped; 1200 programmers were sacked and ~$250 million (seems to big, given heading!) was written off. Important to remember that the banks are amongst the *best* software developers, since it is absolutely critical to their business. Therac 25 - Radiation death courtesy of the computer - Therac 25 was a radiation therapy system in the states. A programming error involving a decimal point went undetected before delivery, resulting in doses 10 times too high. At least six people died. McKinsey’s PeopleNet - McKInsey, a major international consulting firm, decided to unify their personnel systems worldwide in mid to late 80s. After 3 years it was not finished and the project abandoned. The problem of integrating the widely differing regulations etc. proved to be too complex - analysis should have shown this. - and McKinsey are the people you go to when you have a problem! New Jersey Department of Motor Vehicles - In 1984, they decided to replace their database system using you-beaut modern techniques (4GL etc). When the new system was delivered, they cut across to it and the old one was decommissioned. On the first day of use, the overnight run took ~18 hours. By the end of the week, it was taking ~28 - clearly an impossible situation. The system “worked”, but performance testing had not been done. The old system had to be recommissioned, at a cost of "wasn't revealed but in the millions". Microsoft’s first database - Omega - Microsoft Access has been a very successful personal database product. Most people forget, however, that it is their fourth attempt. MS’s first three personal database products sank without trace. MS eventually bought the company that produced Access. cf. Windows 3 and Windows NT 4. And Microsoft is a leader in software development. Australian Customs Service - Intelligence Gathering System - Decided to replace their intelligence system. The resultant system, at a cost of ~$A 3 million, proved to be so difficult to use that the only people who used it were the data entry operators. It was effectively a write-only system! (The intelligence people had decided to develop it themselves, rather than have the systems people do it) A later review decided that it might be worth spending another ~$100,000 to try to save it, but that it would probably have to be written off. Denver International Airport - A new ~$3 billion airport, the DIA had an automated cargo distribution system, involving motorized carts. When the system was first tested, it was chaos, with carts colliding, running off course, etc. Fixing the control software delayed the opening of the airport by a year, at a cost of 100s of millions of dollars. London Metropolitan Ambulance System - In the mid 1980s, a new ambulance dispatch system was developed for LMAS. On delivery, it proved to be disastrous. Ambulances were dispatched to non-existent addresses. When calls were received, ambulances 10km from the emergency were dispatched when others were much closer. People died.
  • A Cautionary Tale In E-Trade's Glitch Crash Shows Internet's Vulnerability By Mark Leibovich Washington Post Staff Writer Monday, February 22, 1999 The chief technology officer was working on 90 minutes' sleep, a fitful night even by her three-hour norm. Now, shortly after the stock market opened Debra Chrapaty was seeing red on her monitor, and red meant crisis. It meant hundreds of thousands of online investors could not buy or sell stocks through E-Trade, the Internet brokerage whose computing operations she directed. She took a Tagamet pill to soothe her ulcer. Meanwhile, in a Silicon Valley schoolyard, E-Trade communications chief Lisa Nash was pledging allegiance to the flag, a ritual she performs with her two daughters every morning. Her beeper pierced the formality with the Code Red news and Nash kissed her daughters goodbye. On Wednesday, Feb. 3, one of the Internet's highest fliers was effectively grounded by a software glitch. E-Trade's 700,000 account holders were locked out of their online portfolios as the stock market was dropping in heavy trading. Every second E-Trade didn't work could threaten its viability, like a body deprived of oxygen. Internet time is unforgiving, and so are subscribers with money at stake. "Get it together E-Trade," a subscriber railed in an online chat forum, "Or you're going to the E-Grave." E-Tolerance? The Internet engenders little when problems occur, a reality that was slammed home at E-Trade this month. Online services now are perceived as utilities, not luxuries. In short order, subscribers have come to demand light-switch reliability when they tap their keypads, never mind the unfathomably complex technology underpinning those commands. As the Internet has bred exhilaration, user expectations likewise have soared, and when something goes wrong, look out. Already, two class action lawsuits have been filed against E-Trade in conjunction with this month's breakdowns. "Technology fails, and anyone who promises otherwise is full of [it],” Chrapaty said. "Things happen on any given day. My job is not to let our customers notice.” Yet over parts of three days, as its customers could only agonize, E-Trade was laid bare as a public microcosm of Internet frailty. It also became a corporate case study of crisis management in the Internet age, the desperate side of the exhilaration. Chrapaty and Nash were steeped in the ordeal : Chrapaty, 38, a former technology chief for the National Basketball Association, led the high-tech paramedics from E-Trade's offices in Alpharetta, Ga.; Nash, 40, a former State Department intern, headed damage control from the company's headquarters in Palo Alto, Calif. "We need to perform with militaristic excellence," said Chrapaty, invoking the preferred imagery of chief executive Christos M. Cotsakos, a Vietnam War veteran who was awarded the Purple Heart: "We need to operate with the souls of warriors." 'Wired to Wall Street’ E-Trade is one of the emerging Internet brands to invade contemporary lives, a dual product of the online boom and raging bull market. Now the third -largest Internet brokerage, E-Trade Group Inc. processes 60,000 trades a day. Some subscribers have given up their jobs to ride the gamblers' surge of "day trading," tying fortunes to the stock market and seizing some control of its fluctuations through E-Trade. They pay nothing to subscribe and keep a minimum $1,000 trading balance in their accounts. E-Trade receives $14.95 or $19.95 commissions on each trade, depending on what exchange the stock is listed. Traditional brokerages typically charge twice that. "Good morning is being replaced by 'Did you buy any Yahoo today?,' ” said Jerry Gramaglia, E-Trade's vice president of marketing, whose three children -- ages 10, 12 and 16 -- each have E-Trade portfolios. "We offer the empowerment and thrill of being wired to Wall Street." Unless subscribers can only see "Error" messages. Which is why, on that Wednesday morning, Chrapaty's red eyes were fixed on a hideous number. Her monitor revealed that E-Trade's transaction "per second" ratio was well below normal -- and dropping fast. She deduced access problems. Chrapaty called in her "super-smarts," a team of eight engineers who would root out the cause of the interruption. They laid out the symptoms, analyzed abnormalities and ate Krispy Kreme doughnuts. It took 30 minutes to isolate the problem, a software upgrade performed the night before. E-Trade technicians had added lines of computer "code” to speed the process by which subscribers had their trades confirmed. But instead, the new coding infected the site with a most toxic side effect: no one could trade. Going Into Battle Lisa Nash arrived at E-Trade's headquarters at 7:30 a.m., Palo Alto time, on Wednesday. She made a beeline for the "Wall Street" conference room, where 12 executives crowded around a speaker phone as the Alpharetta team explained the situation. Nash wrote "talking points" for customer and media inquiries. This service interruption had nothing to do with site volume, Nash emphasized, and E -Trade could easily handle its daily trade capacity. What's more, only the trading portion of E-Trade didn't work; users could still find stock quotes, financial news and other data. A "reserve team" of 40 customer service managers was activated downstairs, near the cot where Chrapaty often sleeps. Chief operating officer Kathy Levinson appeared on CNBC early in the afternoon; Cotsakos was flying and essentially out of pocket. Chrapaty explained the technical arcana to Levinson over the phone. Chrapaty then watched Levinson a few seconds later on television. “ It made me realize how closely people were watching us," Chrapaty said, calling the experience "slightly horrifying." Not as horrifying as what some E-Trade customers were telling company officials, reporters and online chat groups. Nash launched a crisis-specific e -mail address, which received 2,500 inquiries that day. She also led an outbound phone blitz, where company executives personally called hundreds of "high-volume" customers. Trading was halted for 75 minutes from 10:15 a.m. and 11:30 a.m., New York time. The technical staff placed a "patch" over the bad code to let trading resume. After the market closed, technicians removed the bad code entirely -- or so they thought. Chrapaty ordered pizza for her Alpharetta staff Wednesday night, while Palo Alto staff members ate sushi by the takeout bag. Nash, who did 50 interviews Wednesday, also took repeated calls from her daughters, ages 6 and 10. "We saw E-Trade on TV," they kept telling her. Nash slept four hours Wednesday night, Chrapaty two. Code Red -- Again They awoke to a bitter deja vu. Trading was down again Thursday. E -Trade blamed Thursday's troubles on another "aftershock" from the Tuesday upgrade. Some of the troubled code had bled into the site's trading area again, although not all subscribers were affected this time. Whose fault was this anyway, a reporter asked? "We don't do fault,” Chrapaty said briskly. Chrapaty, who is based in Palo Alto, had previously led her team in "team- building" exercises to instill battle readiness. Rope courses, trust falls and more elaborate sessions, such as giving out water pistols, donning a bull's -eye T-shirt and telling everyone to soak her. This drained aggression and promoted harmony, Chrapaty said. It also forged cohesion and composure during crises. Thursday's crisis lasted more than two hours. Nash's routine changed little, except that she skipped "flag salute." But this morning reporters were asking about something else: The New York state attorney general's office had just announced it was investigating the online trading industry after "dozens of complaints" from customers. Such regulatory inquiries, while certainly unwelcome, invite an easy response to the press: "E-Trade is cooperating fully with the investigation," Nash said in many variations Thursday. She emphasized that New York was investigating several online brokers, not just E-Trade, and that it was unrelated to that week's troubles. After the market closed, Chrapaty held a "town meeting" for her staff. She said she was proud of everyone, told a few they were "champs" and "stud muffins," and gave out hats and T-shirts. Then she signed autographs. A Shock to the Stock Friday dawned with sublime quiet and smooth E-trading throughout the morning. It all exploded again at 12:20 p.m. with a 29-minute interruption. "We believe we've got it all fixed," Nash assured Bloomberg News. "But then again, we believed that this morning." E-Trade staffers complained that the press was picking on them. If they had a 29-minute failure six months ago, no one would have noticed. The attention was a perverse rite of the company's rapid growth and popularity. "I find the attention frustrating," Chrapaty said. "And also flattering." Either way, Feb. 3, 4 and 5 offered a cautionary lesson in the fallibility of Internet commerce coupled with the volatility of stock-market livelihoods. Wall Street's reaction was not flattering -- or forgiving. Shares of E-Trade closed the week at $48.93 3/4, down from the 52-week high of $62.43 3/4 it reached that Monday. The stock closed Friday at $40.12 1/2 on the NASDAQ Stock Market. Nash split her weekend between debriefing calls and a family hike. Chrapaty flew to Charlotte Saturday for her great-nephew's birthday, spent $1,000 on presents at Toys R Us, flew back to Alpharetta that afternoon and returned to Silicon Valley on Sunday. There, Chrapaty found a gift assortment of cookies and oranges, and some neighbors sent over roses. "Listen guys," she said by way of thanks. "I'm not dead yet."
  • Example of expenditure on generic software: Windows 2000. Launched Feb. 17, 2000 The long-awaited program has been more than three years in the making and cost an estimated $US1 billion ($A 1.58 billion) in development costs. The program itself is one of the largest works of software ever commercially marketed.

Lectures 1A and 1B Lectures 1A and 1B Presentation Transcript

  • Software Engineering: Analysis and Design - CSE3308 David Squire [email_address] Room 5.23A B Block, Caulfield G12, Building 63, Clayton 9903 1033 (thanks to Martin Dick for initial development of course resources) CSE3308/DMS/2001/2
  • Lecture Outline
    • Course Outline
    • What is Software Engineering?
    • Why Bother with Software Engineering?
    • Product and Process
    • The Software Development Lifecycle
  • Course outline
    • Objectives
    • Assessment
    • Passing the Subject
    • Lectures, the lecturer and consultation
    • Recommended reading
    • Assignment Work
    • Web Pages
    View slide
  • Objectives
    • An understanding of analysis and design
    • A knowledge of the difficulties of specifying and producing large software products
    • An awareness of the problems of managing large software development projects
    • A knowledge of the tools used to analyse and design systems
    • Some knowledge of modern commercial software engineering practice
    View slide
  • Assessment and Passing
    • This will consist of two components:
      • An examination worth 40% of the marks
      • Assignments worth 60% of the marks There will be two practical assignments:
        • A group project worth 45%
        • An individual assignment worth 15%
    • You need to achieve 50% in both the exam and the assignments and achieve an overall mark of 50%, i.e.
      • You must get at least 20 marks out of 40 for the exam
      • You must get 30 marks out of 60 for the assignments
      • You must get 50 marks out of 100 overall
  • Lectures
    • Lectures will be held in lecture room S6 at 2:00pm on Wednesdays and C1 at 2:00pm on Thursdays
    • Notes for each week will be made available on the subject web page in PowerPoint and Postscript formats
      • At some lectures notes will be distributed, when student work on the notes is necessary
      • It is your responsibility to ensure that you have copies of all notes, including the assignments
    • All lecture material and assignment work is examinable
  • Lecturer and Consulation
    • Lecturer: David Squire Room 5.23A Building B - Caulfield campus Email: David.Squire@csse.monash.edu.au Phone: 9903 1033
    • Consultation times at Clayton campus:
      • Wednesday 3pm - 5pm, building 63, room G.12
      • Thursday 3pm - 5pm, building 63, room G.12 (note: these times may change - check subject web site)
  • Recommended Reading
    • There is no prescribed text. The following books cover the basic material in the course:
      • Booch, G., Rumbaugh, J., and Jacobson, I. The Unified Modeling Language User Guide (1998) Hargrave Library: 005.12 B724U
      • Yourdon, E.: Modern Structured Analysis (1989) Hargrave 004.21 Y81M
    • The lecture notes are long and detailed - the intent is to give you the material you will need
    • A list of further useful books is provided in your course outline
  • Assignment work
    • All work submitted by a group must be solely the work of that group
    • All work submitted by an individual must solely be the work of that individual
      • This is not to mean that you may not consult with others, but: If you receive any help, you must specifically acknowledge that person in your submitted work
      • If any student or group of students submits work which is not their own, they will be disciplined according to the University and Faculty policies - see the subject web site
      • Penalties range from exclusion from University to zero marks for the subject
  • Web pages
    • The subject web site can be found at: http://www. csse . monash . edu .au/courseware/cse3308/
    • From week 2, information will include:
      • Lectures (in Powerpoint and Postscript formats)
      • Assignment specifications (in Microsoft Word and Postscript formats)
      • Links relevant to the subject
    • You should check the subject web site each week
  • What is Software Engineering?
    • Group Exercise
    • Break into groups of 4 or 5 (i.e. your neighbours, don’t move around the theatre)
    • Take 5 minutes to write down a definition of software engineering - this can be in point form
    • After 5 minutes, we will collect definitions from the class
  • What is Software Engineering?
    • Many Definitions
      • “… the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” (Bauer 1969)
      • “ The application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation.” (Boehm 1981)
      • “ The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software.” (IEEE 1993)
      • Designing, building and maintaining large software systems in a cost-effective way.
  • Why bother with Software Engineering?
    • Many very successful projects don’t use software engineering
      • examples - early Microsoft, Doom, Hotdog
      • but they are often not repeatable
    • Many more projects fail because they don’t use software engineering. Failures occur because:
      • of the size of the project relative to previous efforts
      • key personnel have left
      • of failure to understand requirements
      • the project delivers, but lacks the required quality
      • of the introduction of new technology
      • of many, many other reasons
  • Some classic disasters
    • CS90 - How Westpac wasted $250 million
    • Therac 25 - Radiation death courtesy of the computer
    • McKinsey’s PeopleNet
    • New Jersey Department of Motor Vehicles
    • Microsoft’s first database - Omega
    • Australian Customs Service - Intelligence Gathering System
    • Denver International Airport
    • London Metropolitan Ambulance System
  • From E-Trade to E-Grave
    • 3rd largest on-line stockbroking service in the world
    • 60,000 trades a day
    • February 3rd - 75 minutes downtime after slow access
    • February 4th - More downtime
    • February 5th - 29 minutes of downtime
    • Two class action law suits
    • Stock price dropped from US$62 to US$48
  • Some statistics
    • One in four systems miscarry
    • 20% turnover in staff is not uncommon
    • Major corporations have up to a 30 month backlog
    • Large systems take 3 to 5 years to develop
    • Corporations are spending up to 20% of revenue on Information Technology
    • Year 2000 problem took up to 50% of resources in at least one bank in Australia. Many of the systems were built in the 1980s
  • Product and Process
    • Both are key aspects in software engineering
    • We move from an emphasis on product to process, and back and forth
      • Structured programming - Product
      • Structured analysis and design - Process
      • Data encapsulation (OO languages) - Product
      • Capability Maturity Model/ISO9000 - Process
      • Next step?
    • We need to be able to deliver quality software products to our customers with a consistent, well-managed and cost-effective process
    • Product and process are not a dichotomy
  • The Software Product
    • Is not the same as a hardware product
      • Software is developed or engineered, it isn’t manufactured like a personal computer
      • Software doesn’t wear out
      • Most software is custom-built, rather than being assembled from existing components
    • A software product should
      • perform the required function
      • be reliable
      • be maintainable
      • be efficient
      • have an appropriate user interface
      • have an appropriate lifetime
  • A good software product?
  • The Software Product
    • Is composed of
      • Programs
      • Data
      • Documentation
    • Two main types of product
      • Generic - eg. Windows, Macintosh application software
      • Bespoke - Systems created for specific application areas
    • Most software expenditure is generic
    • Most software development effort is bespoke
  • The Software Process
    • The set of activities and associated results which produce a software product
    • The sequence of steps required to develop and maintain software
    • Sets out the technical and management framework for applying methods, tools and people to the software task
    • Definition:
      • The Software Process is a description of the process which guides software engineers as they work by identifying their roles and tasks.
  • Characteristics of a good process
    • Understandability
    • Visibility
    • Supportability
    • Acceptability
    • Reliability
    • Robustness
    • Maintainability
    • Rapidity
  • Two questions
    • Is there a right process for software engineers to adopt?
    • Will having a good process guarantee a good product?
  • When do we need process?
    • We always have some process!
    • The larger the project, the greater the need for a formal process
    • Complexity of building a system when related to size is not linear.
  • Determining Process
    • Several Schemes
    • US Department of Defense use the Project Formality Worksheet
    • Projects rate between 12 (minimal formality) to 60 (maximum formality)
    • Most student projects are well under 20 and require very minimal formal process to be successful
  • Steps in a Generic Software Process
    • Project Definition
    • Requirements Analysis
    • Design
    • Program Implementation
    • Component Testing
    • Integration Testing
    • System Testing
    • System Delivery
    • Maintenance
  • Process Activities (1)
    • Project Definition
      • States the purpose of the project
      • Makes initial decision on political and technical feasibility of the project
    • Requirements Analysis
      • High level definition of the functionality of the system, primarily from the point of view of the users
    • Design
      • Looks at the software requirements of the system and the architecture of the system
      • Lower level design activities - data structures, interface representations, procedural (algorithmic) details
  • Process Activities (2)
    • Program Implementation
      • Writing or generating the code to build the system
    • Component Testing
      • Testing of the individual components while they are being built and after they have been completed
    • Integration Testing
      • Testing of the way individual components fit together
    • System Testing
      • Testing of the whole system usually in concert with the users (acceptance testing)
  • Process Activities (3)
    • System Delivery
      • Implementation of the system into the working environment and replacement of the existing system
    • Maintenance
      • Corrective
      • Adaptive
      • Perfective
  • Types of Software Processes
    • Traditional/Waterfall
    • Prototyping
    • Rapid Application Development (RAD)
    • Evolutionary
      • Incremental
      • Spiral
      • Component Assembly
    • Formal Methods
    • Fourth Generation Techniques
  • The Waterfall Model Project Definition System Delivery Maintenance Requirements Analysis Design Component Testing Integration Testing System Testing Program Implementation
  • Waterfall Model
    • Most widely used
    • Each step results in documentation
    • May be suitable for well-understood developments using familiar technology
    • Not suited to new, different systems because of specification uncertainty
    • Difficulty in accommodating change after the process has started
    • Can accommodate iteration but indirectly
    • Working version not available till late in process
    • Often get blocking states
  • Prototyping
    • Specifying requirements is often very difficult
    • Users don’t know exactly what they want until they see it
    • Prototyping involves building a mock-up of the system and using to obtain for user feedback
  • Prototyping Listen to Customer Build/Revise Mock-up Customer test-drives mock-up
  • Prototyping
    • Ideally mock-up serves as mechanism for identifying requirements
    • Users like the method, get a feeling for the actual system
    • Less ideally may be the basis for completed product
      • prototypes often ignore quality/performance/maintenance issues
      • may create pressure from users on deliver earlier
      • may use a less-than-ideal platform to deliver e.g Visual Basic - excellent for prototyping, may not be as effective in actual operation
  • Rapid Application Development
    • Similar to waterfall but uses a very short development cycle (60 to 90 days to completion)
    • Uses component-based construction and emphasises reuse and code generation
    • Use multiple teams on scaleable projects
    • Requires heavy resources
    • Requires developers and customers who are heavily committed
    • Performance can be a problem
    • Difficult to use with new technology
  • Rapid Application Development Business modelling Data modelling Process modelling Application generation Testing and turnover Team 1 Team 2 Team 3 Business modelling Data modelling Process modelling Application generation Testing and turnover Business modelling Data modelling Process modelling Application generation Testing and turnover
  • Incremental Development
    • Applies an iterative philosophy to the waterfall model
    • Divide functionality of system into increments and use a linear sequence of development on each increment
    • First increment delivered is usually the core product, i.e only basic functionality
    • Reviews of each increment impact on design of later increments
    • Manages risk well
  • Incremental Development 1st Increment 2nd Increment 3rd Increment 4th Increment Project Definition analysis delivery design coding testing analysis delivery design coding testing analysis delivery design coding testing analysis delivery design coding testing
  • The Spiral Model
    • Development cycles through multiple (3-6 task regions (6 stage version)
      • customer communication
      • planning
      • risk analysis
      • engineering
      • construction and release
      • customer evaluation
    • Incremental releases
      • early releases may be paper or prototypes
      • later releases become more complicated
    • Models software until it is no longer used
  • Spiral Model
  • Spiral Model
    • Not a silver bullet, but considered to be one of the best approaches
    • Is a realistic approach to the problems of large scale software development
    • Can use prototyping during any phase in the evolution of product
    • Requires excellent management and risk assessment skills
  • Component Assembly
    • Incorporates features of the spiral model
    • Usually based on object technologies, but not necessarily e.g Visual Basic
    • Compose applications from pre-packaged software components
    • Can greatly boost productivity and reuse
    • Relies heavily on quality and robustness of the software components
    • Fits into the Engineering/Construction task region of the spiral model
  • Component Assembly
  • Formal Methods
    • Use of mathematical techniques to specify the requirements of the system e.g Z, VDM, Object-Z
    • Mainly used in life or mission-critical applications, e.g heart pacemakers, NASA
    • Can get very high quality software
    • Problems
      • Time-consuming and expensive
      • Few developers have necessary skills, so extensive training required
      • Difficult to use as a tool to communicate with users
  • Fourth Generation Techniques
    • The use of CASE and 4GL tools which let you specify the software at a high-level
    • Example: Hamilton-1 uses a formal specification language to generate complete system from requirements analysis ($100,000 per license)
    • Use of 4GT has grown considerably in the last decade
    • Some indications of productivity improvements for small and intermediate applications
  • Fourth Generation Techniques
    • Large projects require as much or more analysis, design and testing to achieve the time gains from the elimination of coding
    • Often problems with efficiency of automatically generated code