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

My Contact Info My office hours:  Office: POST 103 1rst Floor or Post 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  My phone: My Web: Moodle: ecampus.adelphi.eduecampus.adelphi.edu

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

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

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.

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

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

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

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

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

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

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.

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

Template Excel:  Mini - charting-in-excel/ Mini - charting-in-excel/  Full - chart-excel Full - chart-excel  Write activities, start and end dates, and people  Sort by start dates  Bar chart MS Project - ideal

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

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

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

Waterfall VS Agile Copyright © 2010 AgileInnovation

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

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

The extreme programming release cycle 21Chapter 3 Agile software development

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

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

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

The Life of an Iteration Copyright © 2010 AgileInnovation

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

The Scrum process 28Chapter 3 Agile software development

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

Control Document – Burndown Chart Break to the Burn down ppt

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

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.

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.

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).

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

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