Schach - Chapter 1 Page 12

1. The Software Crisis Commercial software tends to be delivered... • ... late • ... over budget • ... loaded with bugs Negatively affected by this are: • The software industry, who appears unprofessional. • Our clients, who depend on us. • Their customers, who depend on them. Schach - Chapter 1 Page 12

2. Software Planning When developing software, it is useful to follow a plan • How will the developers communicate with the customer and with each other? • How will the project resources and schedules be determined? • How will the software be designed and how will the design be approved? • How will the code be generated, documented, and tested? • How will customer delivery take place and what mechanisms for feedback will be used? Schach - Chapter 1 Page 13

3. What Is Software Engineering? As software has become more sophisticated, the need to organize its development has greatly increased • System vs. application software • Desktop vs. web applications • Open source vs. proprietary development • Embedded vs. product-line programs • New vs. legacy systems Schach - Chapter 1 Page 14

4. What Isn’t Software Engineering? Software engineering is not... ...an exact science ...the same for every project ...a one-person job ...just software design ...just software development ...just software documentation ...just software testing Schach - Chapter 1 Page 15

5. Science Or Engineering? What’s the difference between “computer science” and “software engineering”? Scientists... Engineers... • investigate what’s true. • investigate what’s true and useful. • extend knowledge. • applyknowledge. • model the real world. • develop products for the real world. • develop tools for engineers. • develop applications for end users. Schach - Chapter 1 Page 16

6. Software Engineering Practices There are several general rules of thumb in the development of software • Identify the value-add • Avoid needless complexity • Focus on common goals • Keep users (incl. fellow developers) in mind • Develop for possible expansion & reuse • Plan ahead & think things through Schach - Chapter 1 Page 17

7. Communication Practices When gathering requirements from customers, effective communication is critical • Be prepared for meetings • Focus on relevant topics • Request clarification as needed • Document all decisions & issues • Avoid adversarial tendencies Schach - Chapter 1 Page 18

8. Planning Practices Once the requirements of the software being developed are clear, it’s time to formulate your plans • Identify & make provisions for risks • Make rough estimates until details solidify • Maintain flexibility & realism Schach - Chapter 1 Page 19

9. Analysis Practices Basically, software projects consist of input, processing, and output, and these three components must be analyzed thoroughly • Understand the sources & destinations of the data • Understand the nature & format of the data • Determine how the data must be manipulated • Identify all internal & external interactions • Organize the functions & behaviors of the software Schach - Chapter 1 Page 20

10. Design Practices Once the project has been effectively analyzed, an implementation plan needs to be fleshed out • Formulate an infrastructure for the software system • Determine what data structures will be needed • Devise the necessary classes and modules • Design inter-module and user interfaces • Use an iterative approach, accenting simplicity Schach - Chapter 1 Page 21

11. Coding Practices Once you’re ready to implement the design, code professionally • Select appropriate languages, tools, platforms, etc. • Accentuate modularity and avoid redundancy • Keep conditionals & loops simple & testable • Make code as reusable & expandable as possible • Document code appropriately • Maintain close contact with other module coders Schach - Chapter 1 Page 22

12. Testing Practices Code is tested in order to uncover errors, so successful tests are those that cause the software to fail • Tests should be designed before code is implemented • Unit tests should be performed on classes & modules • System tests should be performed on integrated code • Customer requirements should be the basis for tests Schach - Chapter 1 Page 23

13. Deployment Practices Mechanisms are needed for delivering software to users, providing customer support, and soliciting feedback • The installation process itself must be fully tested • Help screens & user guides are developed as needed • A customer support infrastructure must be established • Known bugs should be fixed before software delivery • Post-delivery bugs should get high priority Schach - Chapter 1 Page 24

14. Software Life-Cycle Models Traditional models for software development tend to formalize the process into specific tasks and deliverables These approaches are generally considered “predictive” in that they employ up-front effort that (hopefully) enables the development team to accurately predict the rest of the project Schach - Chapter 2 Page 25

15. The Waterfall Life-Cycle Model A systematic sequential approach The Good News: This “big design up front” methodology, in which each step is determined to be absolutely correct before proceeding to the next step, saves time and effort by not forcing early steps to be revisited later The Bad News: It’s virtually impossible to perfect an early stage of the process until you’re deep into the later stages Schach - Chapter 1 Page 26

16. Iterative/Incremental Life-Cycle Model Incrementally producing sequential releases until the entire project is complete The Good News: By developing incremental releases, functionality can be made available as needed The Bad News: Modularization can be difficult, so redundant effort might be inevitable Schach - Chapter 2 Page 27

17. Spiral Life-Cycle Model Evolutionary approach with extensive risk assessment and prototyping Quadrant 1 Determining the current phase’s objectives, alternatives, and constraints Quadrant 2 Analyzing the strategy for achieving this phase’s goals from the viewpoint of risk The Good News: Adapts easily to changes and identifies problems early Commit to approach for the next phase Perform risk analyses and prototyping START The Bad News: Depends heavily on accurate risk assessment In early phases, set up requirements and development plans In early phases, set up simulations and (UML) models In later phases, do detailed design, coding, testing, and releasing In later phases, set up integration and test plan Quadrant 3 Putting into practice a solution to reach the Q1 goals in view of the Q2 risks Quadrant 4 Assessing the results of the risk-reduction strategies and planning the next phase Schach - Chapter 2 Page 28

18. Agile Development The predictive nature of conventional software development is sometimes seen as an illusion An alternative approach, agile development, has arisen recently, characterized by: • Small but highly competent development teams • The principal measure of progress is working code • Changes in requirements are welcome, even if late • Developers, customers, and managers are all on the same team • Software delivery is stressed more than analysis and design Schach - Chapter 2 Page 29

19. Doing More With Less Agile groups are small, but members must be dependable and self-starting Schach - Chapter 2 Page 30

20. Extreme Programming (XP) An agile approach that emphasizes rapid feedback, stressing simplicity, and embracing change EXPLORATION PHASE PLANNING PHASE ITERATIONS-TO-RELEASE PHASE DEATH PHASE PRODUCTIONIZING PHASE MAINTENANCE PHASE continuous review STORIES FOR NEXTITERATION regular updates STORIES effort estimates priorities continuous integration COLLECTIVE DATABASE FINAL RELEASE UPDATED RELEASES feedback SMALL RELEASE TEST customer approval customer approval Schach - Chapter 2 Page 31

21. User Stories The customer specifies the required features of the software being developed, as well as their priorities Schach - Chapter 2 Page 32

22. Pair Programming XP advocates programming in pairs at one workstation to ensure better focus and stronger oversight Unfortunately, this practice sometimes leads to tedium, inequity, or conflict. Schach - Chapter 2 Page 33

23. Scrum Development An agile approach in which prioritized requirements are achieved in strict time intervals with regular team input POSTGAME PHASE PREGAME PHASE DEVELOPMENT PHASE regular updates SPRINT BACKLOG LIST no more requirements PRODUCT BACKLOG LIST SYSTEM TESTING ANALYSIS DESIGN EVOLUTION TESTING DELIVERY PLANNING requirements INTEGRATION SPRINT FINAL RELEASE effort estimates priorities STANDARDS CONVENTIONS TECHNOLOGY RESOURCES ARCHITECTURE HIGH-LEVEL DESIGN/ ARCHITECTURE DOCUMENTATION NEW PRODUCT INCREMENT Schach - Chapter 2 Page 34

24. Software Project Management Effectively planning a software development project, as well as controlling its progress, requires four primary focus areas people product project process Unfortunately, each of these areas can be the source of classic software development mistakes Schach - Chapter 4 Page 35

25. Project Management Mistakes Unsexiest Faculty Alive! People mistakes: • Management undermining motivation • Employing weak personnel (e.g., fast starters - late finishers) • Failure to deal with problem personnel • Dependence on heroics (e.g., last-minute marathon runners) • Adding personnel to late projects (e.g., point of diminishing returns) • Distracting work environments (i.e., difficult to focus in chaos) • Conflicts between customers & developers Schach - Chapter 4 Page 36

26. Project Management Mistakes More people mistakes: • Unrealistic customer/manager/developer expectations • They don’t lengthen schedules, but they do disappoint and dispirit! • Ineffective support from upper management • Lower level managers often react by cutting schedules and features! • Lack of buy-in from stakeholders • Cooperation from relevant personnel is essential to project success! • Accentuating politics over results • Overemphasizing the relationship with management contributes little to overall project progress! • Insufficient early input from users • Late input leads to feature creep! • Pie-in-the-sky wishful thinking • Crossing fingers & clicking heels together does not get a project accomplished! Schach - Chapter 4 Page 37

27. Project Management Mistakes Process mistakes: • Setting overly optimistic schedules • Slipshod analysis, design, and planning frequently result! • Inadequately managing risks • Improper handling of unusual problems may grind a project to a halt! • Jumping into coding • Cutting up-front analysis & design in favor of immediate code production causes long-term problems! • Contractor failure • Outsourced jobs must be carefully managed! • Inadequate planning • Rapid development must be anticipated! • Plan abandonment • Don’t jump ship when schedules slip! • Fuzzy front end • Don’t await final approval to get started! Schach - Chapter 4 Page 38

28. Project Management Mistakes More process mistakes: • Failing to allocate enough time for design • Rushing through initial design makes repeated redesigns inevitable! • Limiting design & code reviews, as well as test planning • Completed features turn out to be not so complete! • Playing catch-up • As unforeseen delays arise, schedules must be adjusted! • “Entrepreneurial” development • Tackling difficulties as they arise is ambitious, edgy,… and doomed! • Omission of less visible tasks from estimates • Some “boring” tasks are essential and time-consuming! • Inadequate tracking of progress • Inform management about schedule slips! • Premature convergence • Don’t prepare a shippable version until ready to do so! Schach - Chapter 4 Page 39

29. Project Management Mistakes Product mistakes: • Overdoing the requirements list • Don’t include tough features in the plan unless they’re really needed! • Feature creep • Don’t allow a multitude of new features to be added to the plan later! • Overdoing the development list • Don’t let developers go crazy trying new things for their own sake! • Horse-trading a schedule slip • Management may “allow” a slip in return for feature list expansion! • Accenting R over D • Don’t depend on unsolved research problems and undeveloped algorithms! Schach - Chapter 4 Page 40

30. Project Management Mistakes Project mistakes: • Depending on a magical silver bullet • Relying upon pr about new technologies usually leads to disappointment! • Expecting significant advantages from new techniques • Risks are often high, while noticeable benefits are usually slow! • Tool-switching in mid-project • Learning curve and rework delays counteract most potential benefits! • Non-automatic control of source code • Ad hoc system integration produces code builds that are unstable! Schach - Chapter 4 Page 41

31. Team Roles Team members are often assigned specific roles to play in a project Manages multiple priorities of conflicting projects; serving as an escalation for team issues that cannot be resolved internally Packages compiled code and configuration files and deploys on appropriate systems via automated software installation procedures (or just copying and running) Ensures consistent reporting, risk mitigation, timeline, and cost control Transforms the requirements created by the FAs into a set of architecture and design documents that can be used by the rest of the team to actually create the solution. Elicit clear requirements from the s.m.e.’s, who may or may not understand how technology can be used to transform the business processes in a positive way Know what the software needs to do and how the process works Provide detail to the s.a.’sarchitecture, including detailed program specs; help developers understand concepts Use techniques ranging from keying in data and playing with the system to formalized, automated testing scripts to ensure the quality of the system and its fit to the f.a. requirements Documents the system and provides instructor- or computer-based training Actually write the code for which the d.l.’sprovided specs Schach - Chapter 4 Page 42