1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 27 Risk in Software Engineering.

Slides:



Advertisements
Similar presentations
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 23 People 1.
Advertisements

CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
Effective Project Management: Traditional, Agile, Extreme
CS 5150 Software Engineering
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 28 Risk in Software Engineering.
CS CS 5150 Software Engineering Lecture 28 People 3.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 25 Delivering the System Business Considerations.
CS CS 5150 Software Engineering Lecture 27 People 2.
CS CS 5150 Software Engineering Lecture 19 Acceptance and Delivery.
Process of Making Multimedia
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 27 Risk in Software Engineering.
CS CS 5150 Software Engineering Lecture 23 People 1.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 27 People 2.
CS CS 5150 Software Engineering Lecture 27 People 3.
CS 501: Software Engineering
CS CS 5150 Software Engineering Lecture 3 Feasibility Studies.
CS CS 5150 Software Engineering Lecture 20 Acceptance and Delivery.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 24 People I.
CS 501: Software Engineering Fall 2000
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 26 Delivering the System.
CS 501: Software Engineering Fall 2000 Lecture 25 Management III Managing People.
CS 501: Software Engineering Fall 2000 Lecture 26 Risk in Software Engineering.
Development and Quality Plans
CS CS 5150 Software Engineering Lecture 26 The Business of Software Development.
Computers & Employment By Andrew Attard and Stephen Calleja.
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp:// Applied Software Project Management Chapter 1: Introduction.
CS 4310: Software Engineering Lecture 14 Risk in Software Engineering.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 3 Feasibility Studies.
Feasibility Studies CS 360 Lecture 2.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
CS CS 5150 Software Engineering Lecture 3 Software Processes 2.
BT Young Scientists & Technology Exhibition App Risk Management.
Prof. Aiken CS 169 Lecture 61 Project Planning CS169 Lecture 6.
Software Engineering Management Lecture 1 The Software Process.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 7 Business Aspects of Software Engineering.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 20 Managing People.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 24 Delivering the System.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies.
CS CS 5150 Software Engineering Lecture 2 Software Processes 1.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 1: Introduction to Systems Analysis and Design Alan.
CS CS 5150 Software Engineering Lecture 2 Software Processes 1.
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
CS CS 5150 Software Engineering Lecture 24 People 2.
CS CS 5150 Software Engineering Lecture 26 People 2.
CS CS 5150 Software Engineering Lecture 5 Feasibility Studies.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 25 People II.
CS SE370 Software Engineering Lecture 5 Feasibility Studies.
CS 5150 Software Engineering Lecture 2 Software Processes 1.
1 Business Aspects of Software Engineering SWE 513.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 27 Software Engineering as Engineering.
CS CS 5150 Software Engineering Lecture 23 People 2.
CS 360 Lecture 20.  The software industry needs to take more responsibility for its products  Products are sold or licensed with no guarantees about.
Feasibility Studies CS 560 Lecture 2 2/2/2016.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
CS 501: Software Engineering Fall 1999 Lecture 20 Management III Managing People.
CS CS 5150 Software Engineering Lecture 26 Professionalism.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 25 Risk in Software Engineering.
INTRODUCTION CSE 470 : Software Engineering. Goals of Software Engineering To produce software that is absolutely correct. To produce software with minimum.
CS 389 – Software Engineering Lecture 2 – Part 2 Chapter 2 – Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
CS 501: Software Engineering Fall 1999
Software Engineering Management
Software Engineering Project Management.
Chapter 18 Maintaining Information Systems
CS 5150 Software Engineering
Chapter 2 – Software Processes
CS 501: Software Engineering
Presentation transcript:

1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 27 Risk in Software Engineering

2 CS 501 Spring 2005 Administration

3 CS 501 Spring 2005 Quiz 4 At what stage during the software development process will the decision be made to outsource the development of the software to an overseas software house? List two aspects of the software development process will not be outsourced?

4 CS 501 Spring 2005 What can be Outsourced? In houseOutsource Feasibility studylead part Requirements analysispart lead System designyes Program designyes Codingyes Testingyes Acceptancelead part Operation & maintenanceyes

5 CS 501 Spring 2005 Professionalism: Planning for the Final Presentation Questions for every presentation 1.Who is the audience? What do they want? 2.What do you want to achieve? 3.How much time do you have? How much can you cover? 4.What facilities are in the room? Who should be there? 5.What materials should you prepare? 6.Do you need a rehearsal?

6 CS 501 Spring 2005 Who is the Audience? What do they Want? Clients The clients have invested effort in this project: Is it ready for production? Should they invest more effort to bring it into production? Should they abandon the project? Course team What has been accomplished? What has been learned? Is the client satisfied? Are you handing over a maintainable system?

7 CS 501 Spring 2005 What do You want to Achieve? Personal and team satisfaction in handing over a good piece of work to the client Complete the course in good style with good grade A clean handover without loose ends Perhaps: a good basis for future involvement with the client, team, or this project

8 CS 501 Spring 2005 How much Time do You Have? How much can You Cover? Plan for 45 minutes total. You should cover: Presentation: Brief review of goals Honest summary of achievements and gaps Summary of what is being delivered Demonstration of operational system: Show the system in operation Be honest about gaps, weaknesses, etc. Time for discussion

9 CS 501 Spring 2005 What Materials should you Deliver? When you leave, all that the client has is your documentation and your software. Imagine that you work for the client and are asked to take over this system. What would you want? Materials can be in any format, need not be huge, but must be current. Place your materials on your GForge or other project site.

10 CS 501 Spring 2005 Delivery: Check List for CS 501 Projects Documentation Requirements, updated to reflect delivered system System and program design, updated to reflect delivered system Instructions for: users, administrators, operators Presentation slides, updated to reflect delivered system Business documentation, e.g., copyright license System Source code and matching binary for all programs Installation scripts, etc. Test scripts, test data, and test reports Different projects will have different deliverables

11 CS 501 Spring 2005 Do you need a Rehearsal? You need a rehearsal Will you have a single presenter, a moderator, or with each presenter handing to the next? Decide on the running order of the presentation and stick to it. When will you take questions? How will manage the time? Who will take notes? Do not change the system after the rehearsal !

12 CS 501 Spring 2005 Failures and Risks Software development projects can fail in many ways: Bad software engineering Late, over budget Lack of function, full of bugs, bad performance Changing circumstances Changing markets Better alternatives Changes of management The biggest single source of problems is poor understanding of requirements

13 CS 501 Spring 2005 Managing Risk Manage projects to avoid risk: Open and visible software process => Avoid surprises Continual review of requirements Willingness to modify or cancel projects

14 CS 501 Spring 2005 Canceling a Project Example: Andrew Window Manager (wm) Technically superior to X (MIT's Athena project) in 1986 but... Digital Equipment Corporation turning X into a product with massive support nobody ready to support wm Therefore wm cancelled in 1986, Andrew user interface and applications ported to X

15 CS 501 Spring 2005 Failure to Cancel a Project Example: University F developed a novel programming language. From 1985 to 1989, this was a promising language for simple programming of window-based applications By 1990, it clearly not gaining acceptance beyond University F But development continued for many more years (about $500K) Not cancelled because...

16 CS 501 Spring 2005 Too Big to Cancel! Example: University A has antiquated administrative systems. Senior management decides to replace them all with commercial packages from X. The timetable and budget are hopelessly optimistic. Staff get dispirited. The Chief Information Officer finds another job. A new Chief Information Officer is appointed. What should she do?

17 CS 501 Spring 2005 We are doing it the Wrong Way! Example: University B has a (big) joint project with Company Y to develop a new computer operating system. After two years work, a junior software developer persuades the university leader that the technical approach is wrong. What should the university do? What should the company do?

18 CS 501 Spring 2005 How to Stop Gracefully It is harder to cancel a project than to start it. It is harder to withdraw a service than introduce it. Considerations The proponents of the system must now reverse their public stance. => Management of expectations Users of the service need a migration strategy. Technical staff must have a graceful path forward.

19 CS 501 Spring 2005 Time to Complete a Software Project Large software projects typically take at least two years from start to finish Formative phase -- changes of plan are easy to accommodate Implementation phase -- fundamental changes are almost impossible Yet many things can change in two years.

20 CS 501 Spring 2005 A Sense of Urgency Example: A not-for-profit corporation is developing a system for a government organization. By 1996 all research had been completed and the system demonstrated successfully with real users. In 2005 the system is still not in full production Reasons: => Incremental improvements to the software => Repeated requests for more functionality => Reluctance to reorganize clerical staff Nobody had a sense of urgency

21 CS 501 Spring 2005 Overtaken by Events Example: University C has a project to develop a digital library system, with funds from Company Z, private foundations and the government. By 1993 an extensive system is running at the university and Z is marketing the technology to its customers. By 1994 it is clear that web browsers and web formats (though technically weak) are becoming widely adopted. => What should the university do? => What should the company do?

22 CS 501 Spring 2005 Changing Requirements and Design Example: The CNRI Handle System -- a high performance, distributed system to map names to resources ( ). Design decisions made in 1994 had to be changed. In 1994 only Web browser was Mosaic In 1994 Java did not exists In 1994 mirroring and caching utilities were not available In 1994 commercial interest was limited Software was rewritten and greatly improved in 1998/9. In 2005, it is widely used by publishers (as DOI) and libraries. If a job's worth doing, it's worth doing twice!

23 CS 501 Spring 2005 Changes of Leadership Many projects are wasted because of management changes Example: In 1988, Company W gave University D $1,000,000 to port a new operating system to its personal computers. The work was well done, on time. Company W changed its president and senior technical staff during the project. The work was wasted. A decade later and several presidents later, Company W is building its future around a modern version of the same operating system. A graduate student from University D is now Senior Vice President of Company W!

24 CS 501 Spring 2005 Client Oversight When work is out-sourced, the client must be vigilant. Example: Company G was the world's leader in software for optimization (e.g., linear and integer programming). G had implemented several packages for various manufacturers. An computer company H contracted with G to develop an optimization package for its new operating system. The package was late, performed badly and disliked by customers. What went wrong? What can we learn?

25 CS 501 Spring 2005 Too Difficult! A development team at University E was given government funds to build a high-performance gateway from protocol x to protocol y. A promising young developer was hired and assigned to this task The project was too difficult for him, but he hid his problems for many months. The project produced nothing of value. What can we learn from this experience?

26 CS 501 Spring 2005 Accept the Obvious! Six organizations were funded by the National Science Foundation, for one year, to develop demonstration projects. The National Science Foundation hoped that the six organizations would then submit a multi-million, five year proposal to develop the production system together. but... there were differences (technical and personal) between the organizations. Three weeks before the proposal was due, the principal investigator at University Q decided that the plan was doomed to failure. What should he do?

27 CS 501 Spring 2005 Engineering and Marketing Corporate engineering & marketing divisions at cross purposes: Examples: Xerox's Palo Alto Research Center pioneered window managers, Ethernet, graphical user interfaces, font managers, etc, => Apple, Adobe, Digital, etc. brought them to the market IBM would not bring its first Unix workstation to the market until the software had been largely rewritten => Sun's early workstations were unreliable but sold well

28 CS 501 Spring 2005 Senior Management Dynamics Directors and shareholders appoint the President => The President does not want to admit failures The President appoints the Chief Information Officer => The CIO does not want to admit failures The CIO appoints the computing managers => The computing mangers do not want to admit failures The computing managers appoint the developers => The developers do not want to admit failure Everybody pretends that things are going well

29 CS 501 Spring 2005 Senior Management Dynamics At last the troubles can not be hidden... Directors and shareholders try to blame the President The President tries to blame the Chief Information Officer The CIO tries to blame the computing managers (and grumbles about the President) The computing managers try to blame the developers (and grumble about the CIO) The developers grumble about their managers What can we do better?

30 CS 501 Spring 2005 Sobering Thoughts Major computing projects are very complex. Inevitably there are delays and failures. Few organizations know how to manage risk & uncertainty. The best CIO's => Manage to minimize risk => Have the confidence of their staff who keep them truthfully informed => Have the self-confidence to keep their seniors truthfully informed

31 CS 501 Spring 2005 The End Software is expensive. Understand who is paying and what they want Good processes help the development of good software: the limits of heroic efforts Software engineering is a craft, not a fixed procedure Minimize risk: visible process function v. time v. cost The importance of people If the requirements are not well understood, the system will fail!