Software Engineering Overview - George Washington University

23
1

Transcript of Software Engineering Overview - George Washington University

Page 1: Software Engineering Overview - George Washington University

1

Page 2: Software Engineering Overview - George Washington University

2

Page 3: Software Engineering Overview - George Washington University

It is not just programming.

Cartoon source: http://wwwx.cs.unc.edu/~pozefsky/COMP523_S08/

3

Page 4: Software Engineering Overview - George Washington University

http://computingcareers.acm.org/?page_id=12sunset.usc.edu/~neno/cs589_2003/Week1.ppt

Basic tension of software engineering

better, cheaper, faster — pick any two!

4

Page 5: Software Engineering Overview - George Washington University

What happens when a project is short‐staffed? You end up working in other domain areas. Just because you are software engineers doesn’t mean you won’t have to deal with hardware or won’t have to do technical writing. 

5

Page 6: Software Engineering Overview - George Washington University

PM: Project Management Plan, Project Schedule, etc. Development: Make sure to do your design and plan out/figure out what you got to do before you start coding.  Design & Code Reviews are important.  Peer or pair reviewsIntegration: But it works on my machine; Verification: Do dry runs and keep track of them

Why are the various areas important and what could go wrong without them?

6

Page 7: Software Engineering Overview - George Washington University

Examples:Potential Risk:  HW may not come in timeRisk: difference between risks and issues. Issues are risks that have actualized.  Example: waiting for a computer to do development on and don’t know when the computer will come…what risk mitigation plan can you develop. CM: from source control and baselines to change requests to locked cabinet of assets (avoid things walking away or people developing on different versions of sw); configuration control board; make sure baseline matches requirements (e g right versions of COTScontrol board; make sure baseline matches requirements (e.g. right versions of COTS software)QA: following process such as doing design reviews; also helps in doing causal analysisSystem: setting appropriate permissions, not requiring admin privileges to run your sw(least access); This way if there was a vulnerability, the complete system would not be compromised.Validation example: does the product fulfill its intended purpose

7

Page 8: Software Engineering Overview - George Washington University

Mini Class Exercise

8

Page 9: Software Engineering Overview - George Washington University

9

Page 10: Software Engineering Overview - George Washington University

Development consists of implementation & integration.  linear and sequential

Source: http://delivery.acm.org/10.1145/1770000/1764814/p8‐ruparelia.pdf?key1=1764814&key2=3698244821&coll=GUIDE&dl=GUIDE&CFID=104417691&CFTOKEN=54415256

10

Page 11: Software Engineering Overview - George Washington University

Customer doesn’t see the product till test time…Document driven…

11

Page 12: Software Engineering Overview - George Washington University

12

Page 13: Software Engineering Overview - George Washington University

Agile Alliance (www.agilealliance.org)fi i i il d lA non‐profit organization promotes agile development

Pros:‐Requirements churn is managed (not avoided)‐Customers see progress regularly and have an opportunity to provide input

Cons:‐Need full customer buy‐in to be successfuly‐ hard to see the forest for the trees

One approach for requirements: User Stories

13

Page 14: Software Engineering Overview - George Washington University

Other Methods:i ( )Extreme Programming (XP)

Adaptive Software Development (ASD)Dynamic System Development Method (DSDM)Feature Driven Development

14

Page 15: Software Engineering Overview - George Washington University

Pig Roles: The Pigs are the ones committed to the project in the Scrum process—they are the ones with “their bacon on the line” and performing the actual work of the project.Roles : Product Owner, ScrumMaster, Team Artifacts : Product Backlog, Sprint Backlog, Estimations, and Burndown Charts

Daily stand‐ups3‐week sprintsConsolidated/information documentationConsolidated/information documentationVariety of toolsFormalized ‘done’ checklist

15

Page 16: Software Engineering Overview - George Washington University

Project Goal: drawing of a houseTime frame: 20 minutes

Roles: Project Lead, Sys Eng (requirements), Architect, 2 developers (gets assigned differences parts by the PM), 1 integrator, tester,  customer (me)

Watch out for:DistractionsDistractionsScope CreepSchedule delays (customer availability, equipment deliveries etc)Team members leaving

16

Page 17: Software Engineering Overview - George Washington University

Project Goal: drawing of a houseTime frame: 20 minutes

Roles: Project Lead, Sys Eng (requirements), Architect, 2 developers (gets assigned differences parts by the PM), 1 integrator, tester, product owner,  scrum master (? Me?)

Watch out for:‐disengaged customerdisengaged customer‐How is the team member leaving handled in this case?

Scrum Master:Wikipedia: primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self‐organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.

17

Page 18: Software Engineering Overview - George Washington University

Cartoon sources:http://www.cartoonstock.com/newscartoons/cartoonists/twi/lowres/twin660l.jpghttp://cnx.org/content/m32188/latest/

18

Page 19: Software Engineering Overview - George Washington University

sunset.usc.edu/~neno/cs589_2003/Week1.ppt

The longer a fault exists in software

the more costly it is to detect and correct

the less likely it is to be properly corrected

Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design

detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more

19

Page 20: Software Engineering Overview - George Washington University

20

Page 21: Software Engineering Overview - George Washington University

21

Page 22: Software Engineering Overview - George Washington University

Mini waterfalls.

i. Determine objectives and system requirements – plan; determine constraints and alternativesii. Evaluate alternatives, and identify and resolve risks.  Develop preliminary design.  Initial prototype may be developed to clear uncertainty in requirements/resolve risks.iii. Develop and test next level product.  First full prototype.iv Plan the next iteration/phase Test and show the product to customer to get feedbackiv. Plan the next iteration/phase.  Test and show the product to customer to get feedback. 

A little time is initially spent in each phase followed by several iterations over all four phases. 

Source: http://delivery.acm.org/10.1145/1770000/1764814/p8‐ruparelia.pdf?key1=1764814&key2=3698244821&coll=GUIDE&dl=GUIDE&CFID=104417691&CFTOKEN=54415256

22

Page 23: Software Engineering Overview - George Washington University

23