DOC PREVIEW
CU-Boulder CSCI 5828 - Software Engineering in the Aerospace Industry

This preview shows page 1-2-22-23 out of 23 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Software Engineering in the Aerospace IndustryWhy it is so hardCSCI 5828 - Spring 2010by Jerel MoffattOverview•GAO Study - Large scale project assessment•Standish Group CHAOS Study•Difficulties specific to the aerospace industry•Agile methods vs heavy waterfall methods•Where do we go from hereDisclaimer•Will focus on projects with NASA as customer•NASA is not the bad guy•NASA has done an uncountable number good things•Software engineering is ‘just hard’GAO Study•In February 2010, the United States Government Accountability Office (GAO) did an assessment on selected large scale NASA projects•GAO assessed 19 NASA projects with a combined life-cycle cost of more than $66 billion•Findings were that most missions were over budget, and behind schedule•Of those 19 projects, 4 are still in the formulation phase where cost and schedule baselines have yet to be established, and 5 just entered the implementation phase in fiscal year 2009 and therefore do not have any cost and schedule growth.•9 of the 10 projects that have been in the implementation phase for several years experienced cost growth ranging from 8 to 68 percent, and launch delays of 8 to 33 months, in the past 3 years. •These 10 projects had average development cost growth of almost $121.1 million—or 18.7 percent—and schedule growth of 15 months, and a total increase in development cost of over $1.2 billion, with over half of this total—or $706.6 million—occurring in the last year.•Example - GLORY•Initial baseline cost at $168.9•Cost went way over, and was re-baselined at $259.1• Latest cost Oct. 2009 at $296.1 which is a 14.3% increase since the re-baseline, and a total increase of 75% !Cobb’s Paradox•“We know why projects fail, we know how to prevent their failure -- so why do they still fail?”•- Martin Cobb Treasury Board of Canada Secretariat , Ottawa, Canada •Standish Group CHAOS Study•10 Reasons Projects are late, and/or over budget relating to software developmentSuccess Criteria1. User Involvement -192. Executive Management Support -16 3. Clear Statement of Requirements -15 4. Proper Planning -11 5. Realistic Expectations -10 6. Smaller Project Milestones -97. Competent Staff - 8 8. Ownership - 6 9. Clear Vision & Objectives - 3 10. Hard-Working, Focused Staff - 3TOTAL 100User Involvement•Typically, user involvement consists of: •engineers, operators, and scientists who are located in separate facilities, separate states, or even separate countries•Long distance can hamper communication paths and thus iterative user involvement•Often software developers never even meet some of the users•Politics often plays a role in user involvement, and not for the better•Mars Climate Orbiter mission failed due to famous unit conversion errorMars Climate Orbiter•Mars Climate Orbiter 1998 •Failed due to unit conversion error•Imperial units vs metric•Caused spacecraft to enter Mars orbit at 57 km instead of the planned 140-150 km orbit•Drag likely destroyed the vehicle•Communication errors during testing (between contractor) likely a root cause of this failureExecutive Support & Ownership•Failure consequences are unacceptable•Budgets are high, tax dollars are at stake•Projects failing badly have to explain themselves before congress•Does the project team have a stake?•Often there are no direct incentives for success by individual developers•Contractors may have bonuses, but largely, the business if funded by government money and there are no ‘profits’ to share if success is ample•Who is the boss?•Isn’t always clear who is in charge sine NASA provides oversight and teams also have dedicated executivesClear Statement of Requirements•NASA is big on requirements•Insists on formally documented, tracked, and verified requirements•But requirements are not flexible, or iterative•Requirements are viewed by NASA as being solidified up front via a waterfall process definition•Does not anticipate and/or allow for iterative requirements•Makes it difficult for a contracted organization to implement their own Agile software process beneathProper Planning & Milestones•Schedules are ‘success oriented’•But often failure to meet schedule date is unacceptable•Launch date may be physically unable to move due to planetary alignments•Launch date may be extremely costly to move due to schedules of launch pad activities and launch vehicles•Does not follow 80/20 rule •“20% of a project's features will provide 80% of user benefits”•Missions are built on meeting science (or other mission) objectives not on benefits to the user which may be ‘negotiable’. Everything is decided up-front•Fixes or updates or improvements post launch are often unacceptable or impossibleTesting Schedule Compromised•Due to inability for milestones to slip, there are bound to be consequences•Testing cut short•Integration tests merged with system tests•System tests merged with acceptance tests•Impact of adding requirements understated, and impact of removing requirements is under analyzedCode Bases•Facilities usually develop software for more than one mission•Missions have overlap in code, but not necessarily in process definition or rigor•Changing the code for mission A may also change it for mission B•Different missions have different testing, documenting, and verification processes•Leads to interesting and sometimes costly configuration management concernsConclusion•So we know that projects are over budget and behind schedule•And we know why projects are over budget and behind schedule•This is not a unique problem to aerospace software•Most all software projects have similar concerns, perhaps not as strictWhat would NASA do?•There are two extremes to the pendulum•More strict bloated process, more meticulous and verbose documentation•Streamlined (Agile) processes, only documenting that which provides added benefit•Over the past decade, NASA has been leaning towards the former solution, not the latter•NASA has adopted CMMI to measure their process model•In itself, this does not imply a heavier process, but can add to cumbersome oversight when CMMI is attempted to be flowed down to other organizations who might do things differentlyAgile Methods •Agile software development focuses on iterative development •Uses constant small measurements to evaluate and adapt•Teams focus on meeting


View Full Document

CU-Boulder CSCI 5828 - Software Engineering in the Aerospace Industry

Documents in this Course
Drupal

Drupal

31 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

22 pages

Load more
Download Software Engineering in the Aerospace Industry
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Software Engineering in the Aerospace Industry and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Software Engineering in the Aerospace Industry 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?