1. 1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, haibinz@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz haibinz@nipissingu.ca

2. 2 Lecture 1 Software and Software Process

3. 3 Software’s Dual Role Software is a product –Delivers computing potential –Produces, manages, acquires, modifies, displays, or transmits information Software is a vehicle for delivering a product –Supports or directly provides system functionality –Controls other programs (e.g., an operating system) –Effects communications (e.g., networking software) –Helps build other software (e.g., software tools)

4. 4 What is Software? Software is a set of items or objects that form a “configuration” that includes programs documents data... Program= data structure + algorithm Software = program + document

5. 5 What is Software? software is engineered software doesn’t wear out most software continues custom built “software is hard.”—D. E. Knuth, 1989

6. 6 Wear vs. Deterioration

7. 7 Software development cycle! 1. Programmer produces code he believes is bug-free. 2. Product is tested. 20 bugs are found. 3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs. 4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs. 5. Repeat three times steps 3 and 4. 6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released. 7. Users find 137 new bugs. 8. Original programmer, having cashed his royalty check, is nowhere to be found. 9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones. 10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits. 11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs. 12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch. 13. Programmer produces code he believes is bug-free.

8. 8 Software Applications system software application software engineering/scientific software embedded software product-line software WebApps (Web applications) AI software

9. 9 Software—New Categories Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Also … (see Chapter 32) –Data mining –Grid computing –Cognitive machines –Software for nanotechnologies

10. 10 Legacy Software Why must it change? software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment software must be re-architected to make it viable within a network environment.

11. 11 Software Myths Affect managers, customers (and other non- technical stakeholders) and practitioners Are believable because they often have elements of truth, but … Invariably lead to bad decisions, therefore … Insist on reality as you navigate your way through software engineering

12. 12 Myth 1. If we get behind schedule, we can add more programmers and catch up. Reality: “Adding more people to a late project makes it even later!” “Too many cooks spoil the pie.”

13. 13 Myth 2: Big teams are better! Reality: – –The first UNIX system was built by a team of three people, Dennis Ritchie, Ken Thompson, and Brian Kernighan, and none was the leader per se. – –Various studies indicate that the optimal team size is between 2 and 5, with 3 being the mode. – –Well, certainly a team with fewer than 2 members is not a team! – –With more than 5 team members, team management begins to dominate the work; i.e., each additional person costs more in team management time than he or she adds to potential work time.

14. 14 Myth 3:The program is 95% done! Programmers are among the most optimistic people in the world. They continue to believe in their ability to solve problems instantly even in the face of continued, repeated evidence to the contrary. Each is even more optimistic about him/herself than anyone else.

15. 15 Myth 4. Software is easy to change. Yes, changes are easy to make -- but hard to make without introducing errors. Every change must be verified and rectified Becomes more “brittle” with changes We become hesitant to change software over time -- recognizing

16. 16 Myth 5: All programmers are the same. One experienced programmer was found to be 28 times more effective than another equally experienced programmer! If you have 5 of the first kind, you’ll finish. If you have 5 of the second kind, you won’t! In fact, you might even be able to finish in time with only one of the first kind; if you can arrange the teams so that he or she will not be slowed down by having to communicate with other team members.

17. 17 Myth 6: Testing software or “proving” (using formal verification techniques) software correct can remove all the errors Software limitations are well known Exhaustive testing is impossible Only a relatively small part of the state space can be covered Despite improved testing techniques, no breakthroughs Mathematical proofs advanced -- but even arguments for impossibility of complete proof of correctness Mathematical verification of software may be possible in the future.

18. 18 Myth 7: CASE tools will solve all your problems All the advertisements in the trade magazines promising 1000% improvement in software productivity if you buy the advertised CASE tools! Fred Brooks says: “There’s no silver bullet!” Even the best tool will not make a good programmer out of a bad one. In fact, a bad programmer will use good tools to turn out worse programs more quickly than ever before.

19. 19 Software Engineering Engineering is the application of science to the needs of humanity. This is accomplished through knowledge, mathematics, and practical experience applied to the design of useful objects or processes. Professional practitioners of engineering are called engineers. en.wikipedia.org/wiki/Engineering en.wikipedia.org/wiki/Engineering Software Engineering: –The computer science discipline concerned with developing large applications. –The profession concerned with specifying, designing, developing and maintaining software applications by applying technologies and practices from computer science, project management, and other fields. –(IEEE) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; ie, the application of engineering to software. See: project plan, requirements analysis, architectural design, structured design, system safety, testing, configuration management.

20. 20 A Layered Technology Software Engineering a “quality” focus process model methods tools Glue, framework Technical how to’s

21. 21 A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities

22. 22 Framework Activities CommunicationPlanningModeling –Analysis of requirements –Design Construction –Code generation –Testing Deployment –Delivered, evaluated, feedback provided

23. 23 Umbrella Activities Software project tracking and control: Allows the software team to assess progress against the project plan and take necessary action to maintain schedule Formal technical reviews: Assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next action or activity. Software quality assurance: Defines and conducts the activities required to ensure software quality Software configuration management: Manages the effects of change throughout the software process Work product preparation and production: Encompass the activities required to create work products such as models, documents, logs, forms, and lists. Reusability management: Defines criteria for work product reuse and establishes mechanisms to achieve reusable components. Measurement: Defines and collects process, project, and product measures. Risk management: Assesses risks that may effect the outcome of the project or the quality of the product.

24. 24 The Process Model: Adaptability The framework activities will always be applied on every project... BUT The tasks (work tasks, work products, quality assurance points, projected milestones) for each activity will vary based on: –the type of project –characteristics of the project –common sense judgment; concurrence of the project team

25. 25 The CMMI (The Capability Maturity Model Integration) http://www.sei.cmu.edu/cmmi/cmmi.html The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of process-related activities.

26. 26 The capabilities of the process areas

27. 27 REQM: REQuirement Management PP: Project Planning PMC: Project Monitoring and Control SAM: Supplier Agreement Management MA: Measurement and Analysis PPQA: Process and product QA CM: Configuration Management Process area

28. 28 Process Patterns Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors A template is used to define a pattern Typical examples: –Customer communication (a process activity) –Analysis (an action) –Requirements gathering (a process task) –Reviewing a work product (a process task) –Design model (a work product)

29. 29 Process pattern template Name. Provide a concise, strong name for the pattern, such as Program or Reuse First. Intent. Describe the process pattern in one or two paragraphs, providing if applicable a graphical description of the process pattern. Common graphical notations applied to process patterns include, but is not limited to, flow charts, process diagrams, UML activity diagrams, and data-flow diagrams. Type. Indicate if it is a Task, Stage, or Phase process pattern. Initial Context. Indicate the situation to which the pattern solution applies, and if applicable the entry conditions that must be true before the process may begin. Solution. Describe in detail how to perform the steps/activities of the process pattern. You may also choose, particularly for phase and stage process patterns, to describe management, quality assurance, and risk management issues, as well as indicate potential metrics to collect when working the process. Resulting Context. Indicate the situation/context which will result from performing the process pattern solution, including if applicable the conditions that must be true for the process to be considered complete. Related Patterns. Indicate the other patterns that this pattern is composed of, is a part of, or is associated to. Known Uses/Examples. Indicate where/how the process pattern has been applied in use. For example, the Technical Review task process pattern can be applied to the management of peer reviews, code reviews, model reviews, and management reviews..

30. 30 Process Assessment The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment options are available: –SCAMPI ( Standard CMMI Assessment Method for Process Improvement ) –CBA IPI (CMM-Based Appraisal for Internal Process Improvement) –SPICE (Software Process Improvement and Capability dEtermination) –ISO 9001:2000

31. 31 Assessment and Improvement

32. 32 Personal Software Process (PSP) Recommends five framework activities: –Planning –High-level design –High-level design review –Development –Postmortem stresses the need for each software engineer to identify errors early and as important, to understand the types of errors

33. 33 Team Software Process (TSP) Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. Show managers how to coach and motivate their teams and how to help them sustain peak performance. Accelerate software process improvement by making CMM level 5 behavior normal and expected. Provide improvement guidance to high-maturity organizations. Facilitate university teaching of industrial-grade team skills.

34. 34 TSP (Cont’d) Each project is “launched” using a “script” that defines the tasks to be accomplished –Review project objectives – common goals –Establish roles –Track quantitative data –Identifies team’s development process –Plan for the needed support facilities –Define local standards –Rebalance team workload to achieve a minimum overall schedule –Assess project risks and assign tracking responsibilities for each key risk Teams are self-directed Measurement is encouraged Measures are analyzed with the intent of improving the team process

35. 35 The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!

36. 36 Summary Software –Instructions+data strucutres+documents Software Engineering –The computer science discipline concerned with developing large applications. Software Process –A linear sequences of software development activities.