Your SlideShare is downloading. ×
0
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
week01.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

week01.ppt

741

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
741
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Sausage: http://www.firstmonday.dk/issues/issue6_3/doheny/
  • CS90 - How Westpac wasted $250 million In 1988 Westpac decided to replace their entire banking system, using lots of cutting edge technology (OO etc.) “Core System 90”, and $89 million, five year, project: “ Westpac Banking Corp. had high hopes for Core System 90 (CS90…In 1988, when Westpac launched the $85 million, five-year, soup-to-nuts project, CS90 was slated to redefine the role of information technology at the Sydney, Australia based bank giant. The plan was to create a showcase of decentralized data systems, allowing branch managers to spin out new financial products rapidly using CASE (computer-aided software engineering) tools and expert systems. … But those hopes have been dashed. Last month, more than three years after CS90 was begun, Westpac reluctantly ponied up to the worst: The project is out of control. CS90 has already drained nearly $150 million from Westpac's coffers-and the bank has virtually nothing to show for it. What's more, CS90s scheduled 1993 completion date is now just a pipe dream.” (Information Week, Dec. ’91) Early 1992: “Westpac banking, Australia's largest bank, will eliminate 500 jobs from its development technology area, saving $37 million a year. The action follows the termination of a runaway systems project that cost $150 million-nearly twice the original estimate when the project started in 1988.” 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 http://sunnyday.mit.edu/papers/therac.pdf Between June 1985 and January 1987, a computer-controlled radiation therapy machine, called the Therac-25, massively overdosed six people. Worst in 35 year history of medical accelerators. First in Therac series to rely on software for safety. Earlier models had separate circuits and hardware interlocks. Cryptic error messages “MALFUNCTION N” (1<=M<=64). Not explained in User Manual. No indication of patient risk. Operators could simply “proceed” after a malfunction, by hitting the “P” key Concurrent access to shared memory. Race conditions. Logic error meant that parameters entered by the operator could appear on the screen, but not cause the corresponding internal variables to be modified. Patients received doses 1000s of times higher than prescribed. There was more than one independent, serious software fault. Over-reliance on software – assumption that only hardware fails. Some faults had been present in software reused from Therac-20, but hardware interlocks had prevented accidents, and thus their detection.. McKinsey’s PeopleNet from http://www.prenhall.com/divisions/bp/app/alter/student/useful/ch8mckinsey.html The most important resources for an international consulting company such as McKinsey & Co., are its people. Accordingly, McKinsey set out to develop PeopleNet, a company-wide human resources information to keep track of staffing assignments and related information about the firm's employees. During the project McKinsey encountered many of the common setbacks consultants often help their clients with. As a first foray into client-server computing, the project was a departure from the company's previous focus on mainframes and PCs, and some of the people in the IS group never agreed with the technical approach. The expected infrastructure based on a $20 million telecommunications project was not available because that project was later judged too expensive. Consequently the PeopleNet project had to bear the unexpected burden of building infrastructure incrementally. McKinsey's highly independent branch offices worried that a uniform set of guidelines would reduce their traditional local control over staffing. After many meetings, control of the part of PeopleNet related to tracking staff assignments was given to local offices, which agreed to share with headquarters only a limited amount of personnel data, such as languages spoken, skills, and experience. There were also problems with data discrepancies between the Scandinavian offices and headquarters in New York, resulting in a massive cleanup. Originally seen as a 12 month, $4.9 million project, the revised projections were that it would run 30 months, cost $12 million, and produce a system somewhat different from the one originally envisaged New Jersey Department of Motor Vehicles http://doi.acm.org/10.1145/88636.87943 Figures unverified: In 1984, they decided to replace their database system using 4GL 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. Failure to scale up from prototype. The old system had to be recommissioned, at a cost of "wasn't revealed but in the millions". Microsoft’s first Windows database - Omega http://www.avdf.com/nov96/acc_jet.html http://www.xoc.net/works/architecting_large_programs/default.asp “ Studies have shown that somewhere between 15% and 40% of large software projects fail. The larger the project, the more likely it is to fail. By failure, I mean they are cancelled or postponed, or are never used. DeMarco and Lister in Peopleware found that in over 500 projects they studied, 15% of them failed. Of projects larger than 25 person-years, more than 25% of them failed. Other studies have shown much higher percentages. Entire books have been written about some of these monumental software failures, discussing such projects as the baggage handling system at Denver International Airport. There are many reasons for these failures. These numbers are appalling. This paper addresses technical issues revolving around the design of programs in Visual Basic to address design methodologies s that will give a large project a better percentage chance of succeeding. I'll leave it to others to discuss how to solve management and other issues that contribute to the failure of projects. Just to give you a firsthand example: I worked on one such failure when I worked at Microsoft. I was a Software Design Engineer at Microsoft from 1988 until 1992, working on what became Microsoft Access. However, the first two years, I worked on a Project code-named Omega. Unless you've seen one of the demos of it that Tod Neilson of Microsoft shows from time to time, you've probably never heard of Omega. It was Microsoft's first attempt at a Windows database program. I would guess that somewhere around 200 person-years were discarded when the project was cancelled. I won't list all the reasons for it's demise and the subsequent revival as Microsoft Access, but part of the problem was technical: The program was just too big. If we applied the techniques that I describe in this paper to that project, it might have had a better chance of succeeding. The techniques I'll discuss use the tools supplied by Visual Basic to avoid the technical pitfalls of many software projects. ” Omega didn’t make it, but its scripting language went on to become VB. 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. (from Martin Dick) Denver International Airport http://www.geocities.com/kschottland/dia.html http://www.prenhall.com/divisions/bp/app/alter/student/useful/ch13denver.html The first large-scale airport built in the US for 20 years. The airport was completed behind schedule, and due to complications with the baggage handling system, it was significantly over budget. The initial estimate of the baggage handling system was $193 million (Gibbs, 86). Ultimately the project ballooned to $311 million and only serves one of the three concourses it was designed to handle (Schloh, Comparative). Further, the system serves only half of the airport's eighty-four gates and is only being utilized for flights departing or terminating in Denver. Statistically, this means the baggage handling facility is currently operating at twelve percent of its designed capacity. London Ambulance Service http://legacy.eos.ncsu.edu/eos/info/computer_ethics/risks/safety/medical/study.html http://catless.ncl.ac.uk/Risks/14.48.html#subj3 The Ambulance Chief of London retired in October of 1992 after a new computerized ambulance dispatch service caused delays resulting in the deaths of up to 20 people. Employees were against the use of the new system. Within hours of going online, calls were being missed and multiple ambulances were dispatched to the same site. Incoming calls were delayed longer than usual, as long as 30 minutes. The old system would have handled the load without breaking down. After 36 hours, they reverted to the manual system. Not enough consideration was given to system overload; there appears to have been no backup procedure. Operators of the system were quoted as saying "there was no way to scroll back through the list of calls to ensure that a vehicle had actually been dispatched" and "the exception list just kept growing".
  • 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.
  • Transcript

    • 1. Software Engineering: Analysis and Design - CSE3308 David Squire [email_address] Room 5.23A B Block, Caulfield 9903 1033 101A , Building 26 , Clayton 9905 3295 (thanks to Martin Dick for initial development of course resources) CSE3308/DMS/2003/3
    • 2. Lecture Outline
      • Course Outline
      • What is Software Engineering?
      • Why Bother with Software Engineering?
      • Product and Process
      • The Software Development Lifecycle
    • 3. Course outline
      • Objectives
      • Assessment
      • Passing the Subject
      • Lectures, practice classes, the lecturer and consultation
      • Recommended reading
      • Assignment Work
      • Web Pages
    • 4. Objectives (1)
      • Knowledge of the difficulties of specifying and producing large software products, leading to
        • an appreciation of the need for software engineering methodologies
        • understanding of the distinction between software engineering and programming, and thus the distinction between a software configuration and a program
      • An understanding of, and ability to apply, the methods of analysis and design, including:
        • structured analysis and design using Yourdon notation
          • Context Diagram, Event Lists, Data-Flow Diagrams, Entity-Relationship Diagram, State Transition Diagrams, Process Specifications, Data Dictionary, Structure Chart
        • object-oriented analysis and design using UML
          • Use Cases, Class Diagrams, Interaction Diagrams, State Diagrams, Package Diagrams, Activity Diagrams
    • 5. Objectives (2)
      • Knowledge of , and the ability to apply, principles of user interface design such as affordances, awareness of mental models, visibility, mapping and feedback.
      • An awareness of the problems of managing large software development projects, and the techniques used to address them, including
        • Configuration management
        • Software metrics
        • Validation and verification techniques
        • Quality management
    • 6. Assessment and Passing
      • There are two assessment 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
    • 7. Lectures
      • Lectures will be held at:
        • 2:00pm on Wednesdays, room S6
        • 2:00pm on Thursdays, room C1
      • Notes for each week will be made available on the subject web page in PowerPoint and Portable Document Format (PDF) formats
        • It is your responsibility to ensure that you have copies of all notes, including the assignments
      • All lecture material, worksheets and assignment work is examinable
    • 8. Practice Classes
      • There will be two practice classes each week:
        • 12.00 noon to 2:00pm Thursday, room EH2
        • 11:00am to 1:00pm Friday, room EH2
      • Students are expected to attend at most one practice class per week
      • During a practice class, students are expected to work on practice problems, or on their assignments
      • The lecturer and tutors will be available to comment on, and help with, solutions during the practice class.
      • Practice classes start in week 2
    • 9. Lecturer and Consulation
      • Lecturer: David Squire Clayton, Bldg. 26, Room 101A, Ph. 9905 3295 (Wed., Thu, & Fri., 1st semester) Caulfield, Bldg B, Room 5.23A, Ph. 9903 1033 Email: David.Squire@csse.monash.edu.au
      • Consultation
        • The primary time for consultation is during the practice classes
        • Other consultation at Clayton campus (preferably by appointment): Wednesday 3:15pm - 5pm, building 63, room G.12
    • 10. 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)
        • Yourdon, E.: Modern Structured Analysis (1989)
        • Pressman, R., Software Engineering: A Practitioner's Approach, (2000)
      • 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 the unit outline. Copies of these books are on reserve in the library.
    • 11. 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 unit web site
        • Penalties range from exclusion from University to zero marks for the subject
    • 12. Web pages
      • The unit web site can be found at: http://www. csse . monash . edu .au/courseware/cse3308/
      • Information at the web site will include:
        • Lectures (in Powerpoint and PDF formats)
        • Assignment specifications (in Microsoft Word and PDF formats)
        • Resources and links relevant to the subject
        • Anonymous feedback forum
      • You should check the subject web site each week
    • 13. 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
    • 14. 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.
    • 15. Why bother with Software Engineering?
      • Many very successful projects don’t use software engineering , e.g.
        • early Microsoft
        • ID Software’s Doom
        • Sausage’s 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
    • 16. Some classic disasters
      • CS90 - How Westpac wasted $150 million
      • Therac - 25 - Radiation death courtesy of the computer
      • McKinsey’s PeopleNet
      • New Jersey Department of Motor Vehicles
      • Microsoft’s first Windows database - Omega
      • Australian Customs Service - Intelligence Gathering System
      • Denver International Airport
      • London Ambulance Service
    • 17. From E-Trade to E-Grave
      • 3rd largest on-line stockbroking service in the world
      • 60,000 trades a day
      • February 3rd, 1999 - 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
    • 18. Some statistics
      • One in four systems miscarry
      • 20% turnover in staff is not uncommon
      • Major corporations have a backlog of up to a 30 months
      • Large systems take 3 to 5 years to develop
      • Corporations are spending up to 20% of revenue on Information Technology
      • Y2K problem took up to 50% of resources in at least one bank in Australia. Many of the systems were built in the 1980s
    • 19. 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
    • 20. 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
    • 21. A good software product?
    • 22. The Software Product
      • Is composed of
        • Programs
        • Data
        • Documentation
          • requirements, analysis & design documents, walk-through minutes, test plan, user manuals, etc.
      • often referred to as the “software configuration”
      • 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
    • 23. 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.
    • 24. Characteristics of a good process
      • Understandability
      • Visibility
      • Supportability
      • Acceptability
      • Reliability
      • Robustness
      • Maintainability
      • Rapidity
    • 25. Two questions
      • Is there a right process for software engineers to adopt?
      • Will having a good process guarantee a good product?
    • 26. 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.
    • 27. 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
    • 28. Steps in a Generic Software Process
      • Project Definition
      • Requirements Analysis
      • Design
      • Program Implementation
      • Component Testing
      • Integration Testing
      • System Testing
      • System Delivery
      • Maintenance
    • 29. 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
    • 30. 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)
    • 31. Process Activities (3)
      • System Delivery
        • Implementation of the system into the working environment and replacement of the existing system
      • Maintenance
        • Corrective
        • Adaptive
        • Perfective
    • 32. Types of Software Processes
      • Traditional/Waterfall
      • Prototyping
      • Rapid Application Development (RAD)
      • Evolutionary
        • Incremental
        • Spiral
        • Component Assembly
      • Formal Methods
      • Fourth Generation Techniques
    • 33. The Waterfall Model Project Definition System Delivery Maintenance Requirements Analysis Design Component Testing Integration Testing System Testing Program Implementation
    • 34. 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
    • 35. 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
    • 36. Prototyping Listen to Customer Build/Revise Mock-up Customer test-drives mock-up
    • 37. 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
    • 38. 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
    • 39. 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
    • 40. 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
    • 41. 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
    • 42. 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
    • 43. Spiral Model
    • 44. 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
    • 45. Component Assembly
      • Incorporates features of the spiral model
      • Usually based on object technologies, but not necessarily e.g. Visual Basic (older versions)
      • 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
    • 46. Component Assembly
    • 47. 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
    • 48. 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
    • 49. 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
    • 50. References
      • Pressman, R., Software Engineering: A Practitioner's Approach , McGraw-Hill, 2000, (Chapters 1 and 2).
      • McConnell, S., Less is More: Jump-Start Productivity with Small Teams , Software Development, October 1997, pp. 28-34. http://www. stevemcconnell .com/articles/art06. htm

    ×