SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS. Saulius Ragaišis.

Size: px

Start display at page:

Download "SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS. Saulius Ragaišis."

Theodore Paul
6 years ago
Views:

1 SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS Saulius Ragaišis

2 CSC2008 SE Software Processes Learning Objectives: Explain the concept of a software life cycle and provide an example, illustrating its phases including the deliverables that are produced. Select, with justification the software development models and process elements most appropriate for the development and maintenance of a diverse range of software products. Explain the role of process maturity models. Compare the traditional waterfall model to the incremental model, the agile model, and other appropriate models. For each of various software project scenarios, describe the project s place in the software life cycle, identify the particular tasks that should be performed next, and identify measurements appropriate to those tasks.

3 SOFTWARE LIFE CYCLE

4 Definitions from Google The phases a software product goes through between when it is conceived and when it is no longer available for use. The Free On-line Dictionary of Computing, Denis Howe 2010 A series of stages in the development of an application and is often used in Software Engineering. David Bolton, About.com

5 Standards of Life cycle processes ISO/IEC 12207:2008. Systems and software engineering Software life cycle processes ISO/IEC 15288:2008. Systems and software engineering System life cycle processes

6 Definitions in standards Life cycle - evolution of a system, product, service, project or other human-made entity from conception through retirement. Life cycle model - framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding. [ISO/IEC 12207:2008]

7 Software life cycle processes (ISO/IEC )

8 LIFE CYCLE MODELS

9 Life cycle models and stages The life of a system/software can be modeled by a life cycle model consisting of stages. Models may be used to represent the entire life from concept to disposal or to represent the portion of the life corresponding to the current project. The life cycle model is comprised of a sequence of stages that may overlap and/or iterate, as appropriate for the project's scope, magnitude, complexity, changing needs and opportunities. [ISO/IEC 12207:2008]

10 1970

11 Development according W. W. Royce

12 Iterative development Rocket science!

13 Generic process framework activities Communication Planning Modeling Construction Deployment

14 Waterfall model

15 Incremental model

16 Spiral model

17 RAD model

18 Prototyping

19 Unified Process An extensible framework which should be customized for specific organizations or projects. Proposed by Ivar Jacobson, Grady Booch and James Rumbaugh. The first book The Unified Software Development Process (ISBN ) published in 1999.

20 UP refinements and variations Rational Unified Process (RUP), the IBM / Rational Software development process Oracle Unified Method (OUM), the Oracle development and implementation process Agile Unified Process (AUP), a lightweight variation developed by Scott W. Ambler Essential Unified Process (EssUP), a lightweight variation developed by Ivar Jacobson Enterprise Unified Process (EUP), an extension of the Rational Unified Process

21 UP characteristics Iterative and Incremental Use Case Driven Architecture Centric Risk Focused

22 UP project life-cycle

23 UP major work products: Inception Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment Project plan (phases and iterations) Business model (if necessary) One or more prototypes

24 UP major work products: Elaboration Use-case model Supplementary requirements including non-functional Analysis model Software architecture description Executable architectural prototype Preliminary design model Revised risk list Project plan including iteration plan, adapted workflows, milestones, technical work products Preliminary user manual

25 UP major work products: Construction Design model Software components Integrated software increment Test plan and procedure Test cases Support documentation (user manuals, installation manuals, description of current increment)

26 UP major work products: Transition Delivered software increment Beta test reports General user feedback

27 AN AGILE VIEW OF PROCESS

29 Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.

30 Principles behind the Agile Manifesto (2) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

31 Principles behind the Agile Manifesto (3) Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

32 Most popular Agile methodologies XP (extreme Programming) SCRUM DSDM (Dynamic System Development Method)

33 Key issues stressed by Agile The importance of self-organizing teams that control over the work they perform. Communication and collaboration between team members and between practitioners and their customers. A recognition that change represents an opportunity. An emphasis on rapid delivery of software that satisfies the customer.

34 What we have learned? Concept of software life cycle Understanding of software life cycle processes Software life cycle models

35 QUESTIONS?

36 APPENDIX

37 Life cycle process groups (ISO/IEC ) System Life Cycle Processes Agreement Processes (2 processes) Organizational Project-Enabling Processes (5 p.) Project Processes (7 p.) Technical Processes (11 p.) Software Life Cycle Processes Software Implementation Processes (7 p.) Software Support Processes (8 p.) Software Reuse Processes (3 p.)

38 Agreement Processes Acquisition Process Supply Process

39 Organizational Project-Enabling Processes Life Cycle Model Management Process Infrastructure Management Process Project Portfolio Management Process Human Resource Management Process Quality Management Process

40 Project Processes Project Planning Process Project Assessment and Control Process Decision Management Process Risk Management Process Configuration Management Process Information Management Process Measurement Process

41 Technical Processes Stakeholder Requirements Definition Process System Requirements Analysis System Architectural Design Implementation Process System Integration Process System Qualification Testing Process Software Installation Software Acceptance Support Software Operation Process Software Maintenance Process Software Disposal Process

42 Software Implementation Processes Software Implementation Process Software Requirements Analysis Process Software Architectural Design Process Software Detailed Design Process Software Construction Process Software Integration Process Software Qualification Testing Process

43 Software Support Processes Software Documentation Management Process Software Configuration Management Process Software Quality Assurance Process Software Verification Process Software Validation Process Software Review Process Software Audit Process Software Problem Resolution Process

44 Software Reuse Processes Domain Engineering Process Reuse Asset Management Process Reuse Program Management Process

46 XP project

47 XP planning/feedback loops

48 XP main values Communication Simplicity Feedback Courage Respect

49 XP practices Planning game Small releases System metaphor Simple design Refactoring Test driven development Pair programming Collective code ownership Continuous integration 40 hour week (sustainable pace) On-site customer (whole team) Coding standard

50 XP practices

51 DSDM project phases

52 Prerequisites for using DSDM Acceptance of the DSDM Atern philosophy before starting work. Appropriate empowerment of the Solution Development Team. Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement. Incremental delivery Access by the Solution Development Team to business roles Solution Development Team stability. Solution Development Team skills. Solution Development Team size. A supportive commercial relationship.

53 DSDM principles Focus on the business need Deliver on time Collaborate Never compromise quality Build incrementally from firm foundations Develop iteratively Communicate continuously and clearly Demonstrate control

54 Core techniques of DSDM Timeboxing MoSCoW method for requirements prioritizing Prototyping Testing Workshop Modeling Configuration Management

55 MoSCoW method MUST have this requirement to meet the business needs. SHOULD have this requirement if at all possible, but the project success does not rely on this. COULD have this requirement if it does not affect the fitness of business needs of the project. WOULD have this requirement at later date if there is some time left (or in the future development of the system).

56 SCRUM project

57 Scrum Framework in 30 Seconds A product owner creates a prioritized wish list called a product backlog. During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces. The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum). Along the way, the Scrum Master keeps the team focused on its goal. At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

58 Scrum terminology Scrum Team: Product Owner, Scrum Master and Development Team Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does. Scrum Master: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Development Team: A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint.

59 Scrum terminology (2) Sprint burn down chart: Daily progress for a Sprint over the sprint s length. Product backlog: A prioritized list of high-level requirements. Sprint backlog: A prioritized list of tasks to be completed during the sprint. Sprint: A time period (typically 1 4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.

60 Scrum terminology (3) (User) Story: A feature that is added to the backlog. A story is an independent, negotiable, valuable, estimable, small, testable requirement ("INVEST Acronym"). Theme: A theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific. Epic: An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break it down into it's component stories, which should be done before bringing it into a sprint so to reduce uncertainty.

61 Scrum terminology (4) Spike: A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered. Tracer Bullet: The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code.

62 Scrum terminology (5) Point Scale/Effort/Story points: Relates to an abstract point system, used to discuss the difficulty of the story, without assigning actual hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...), and clothes size (XS, S, M, L, XL). Tasks: Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more than a day to finish.

63 Scrum terminology (6) Definition of Done (DoD): The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. Velocity: The total effort a team is capable of in a sprint. The number is derived by adding all the story points from the last sprint's stories/features. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint. Impediment: Anything that prevents a team member from performing work as efficiently as possible.

64 Scrum terminology (7) Sashimi: A report that something is "done". The definition of "done" may vary from one Scrum team to another, but must be consistent within one team. Abnormal Termination: The Product Owner can cancel a Sprint if necessary. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed. Planning Poker: In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team's velocity.

Agile. How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this?

Agile. How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this? Agile How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this? What is Agile? The term agile (sometimes written Agile) was popularised