1. Senior Seminar in Information Systems Pepper (with credit to both Dr. Chays and Ian Sommerville book slides)

2. My Contact Info My office hours:  Office: POST 103 1rst Floor or Post 217 2 nd Floor (or in lab Post 102) Office Hours:  Tuesday 9:10 – 10:40; 12:30 – 1:30  Wednesday 2:15 – 4:15  Thursday 9:10 – 10:40  Email: pepper@adelphi.edu My phone: 516-297-5241 My Web: www.adelphi.edu/~pe16132www.adelphi.edu/~pe16132 Moodle: ecampus.adelphi.eduecampus.adelphi.edu

3. Major Course Objectives Complete an Information Systems Project  Communication  Documentation and UML  Oral presentations  Project Control  Waterfall and Agile  Gantt and Burndown  Change management: GIT  Design  Design methodology – Waterfall and Agile  Test Driven Design when possible  Design Pattern use  SQL preferred

4. Delivery  Delivery  Real world or simulation  On time (10% reduction per day)  Training and Written guides  Manage expectations

5. Project Content Have a real or potential user for the team to consult user.OR have a potential researcher audience.  For a product to be marketed, find a potential Read and change a file or database, or have a significant project substitution for this requirement Contain a substantial creation component for each team member.

6. Grading Grade Percentages: Oral Presentations - 20% Documentation Deliverables – 40% Code or detailed content Deliverables - 40% 10% per day reduction if late

7. Textbooks UML Distilled by Martin Fowler Practical Software Development Techniques. By Crookshanks, Edward No tests, but you will use all material in your project

8. The software process Activities Needed  Specification – defining what the system should do;  Design and implementation (development) – defining the organization of the system and implementing the system;  Validation – checking that it does what the customer wants;  Evolution – changing the system in response to changing customer needs. A software process model is an abstract representation of a process. 8Chapter 2 Software Processes

9. Plan-driven and agile processes Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. (ex: waterfall) In incremental processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. (ex: Agile, Extreme Programming) In practice, most practical processes include elements of both plan-driven and agile There are no right or wrong software processes. 9Chapter 2 Software Processes

10. #1 Waterfall Method – Plan based with Gates Requirements System Design Coding ( Implementation ) Integration Maintenance reqts. analysis validation Unit test revalidation System Test

11. Testing phases in a plan-driven software process 11Chapter 2 Software Processes

12. Gantt Charts Predecessors & Activity Lengths (man hours)  Critical paths and slack  Lead time and lag time Details: Sub Activities, Teams, People Tracking: Earn man hours. Reproject times to adjust lengths. http://en.wikipedia.org/wiki/Gantt_chart

13. Time Estimates Determine 3 times and weight towards pessimistic  Formulas exist for this: T E = (O + 4M + P) ÷ 6

14. Template Excel:  Mini - http://davidseah.com/node/manual-gantt- charting-in-excel/ Mini - http://davidseah.com/node/manual-gantt- charting-in-excel/  Full - http://www.smartsheet.com/blog/gantt- chart-excel Full - http://www.smartsheet.com/blog/gantt- chart-excel  Write activities, start and end dates, and people  Sort by start dates  Bar chart MS Project - ideal

15. #2 Incremental development 15Chapter 2 Software Processes Prototypes Phases Agile Cycles Test Releases

16. Incremental development benefits The cost of accommodating changing customer requirements is reduced. (less analysis and doc) It is easier to get customer feedback on the development work that has been done. More rapid delivery and deployment of useful software to the customer is possible. Incremental development problems The process is not visible. System structure tends to degrade as new increments are added. 16Chapter 2 Software Processes

17. Painpoints Long Cycle Times Productivity Quality Responsiveness Complexity Brittle Code Your Favorite! Transparency Copyright © 2010 AgileInnovation

18. Waterfall VS Agile Copyright © 2010 AgileInnovation

19. Agile manifesto  Our values:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan  That is, while there is value in the items on the right, we value the items on the left more. Chapter 3 Agile software development 19

20. Plan-driven and agile specification 20Chapter 3 Agile software development separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model – plan- driven, incremental development is possible Iteration within stage Iteration of stage User's full agreement at end, not before code

21. The extreme programming release cycle 21Chapter 3 Agile software development

22. The Parts and the Whole Controller Inspect Set Target Adapt Clean Design & Code & Refactor User Stories - Late Elaboration Shared Code Ownership Test Driven Development….. Iteration Plan Daily Stand- Up Pair Programming Customer Reviews & Feedback Retrospectives AutoTest….. Sustainable pace Collective Ownership with users Minimal documentation for sprint

23. What is a user story: A ‘prescribing medication’ story 23Chapter 3 Agile software development

24. What is a task: Examples of task cards for prescribing medication 24Chapter 3 Agile software development

26. The Life of an Iteration Copyright © 2010 AgileInnovation

27. Scrum  Project Manager's job: - Deliver needed system on time within budget  The Scrum approach - manage the iterations  There are three phases in Scrum.  outline planning phase - general picture and architecture  Sprint cycles releasing increments of the system.  The project closure phase - final delivery, documentation and review of lessons learned. Chapter 3 Agile software development 27

28. The Scrum process 28Chapter 3 Agile software development

29. The Sprint cycle  Every 2–4 weeks (a fixed length).  1) Project team with customer: Look at product backlog - select stories to implement  2) implement with all customer communication through scrum master (protecting pgmr at this point)  Scrum master has project manager role during sprint  Daily 15 min meetings  Stand up often  Team presents progress and impediments  Scrum master tasked with removing impediments  3) Review system release with user 29Chapter 3 Agile software development

30. Control Document – Burndown Chart Break to the Burn down ppt

31. #3 Reuse-oriented software engineering 31Chapter 2 Software Processes

32. Software engineering ethics Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law but involves following a set of principles that are morally correct.

33. Issues of professional responsibility Confidentiality  Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence  Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.

34. Issues of professional responsibility Intellectual property rights  Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse  Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

35. Ethical principles Chapter 1 Introduction35 1. PUBLIC - Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. ACM / IEEE-CS Code of Ethics

36. Summary Course Structure Software Process Models  Plan based – Waterfall control with GANTT  Incremental – Agile control with Burndown  Reuse COTS (commercial off the shelf) Code of Ethics