Presentation is loading. Please wait.

Presentation is loading. Please wait.

SE 501 Software Development Processes

Similar presentations


Presentation on theme: "SE 501 Software Development Processes"— Presentation transcript:

1 SE 501 Software Development Processes
Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 3

2 Contents SDLC’s continued Choosing suitable SDLC Summary
Agile, RUP, TSP, ACDM Choosing suitable SDLC Summary Discussion on Assignment #2 SE 501 Dr. Basit Qureshi

3 Bibliography Humphrey, Watts (1999). Introduction to the Team Software Process. Addison Wesley. Justin Rockwood, “Choose Your Weapon Wisely” CMU, 2003 Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley Lattanze, Anthony J. (2009). Architecting Software Intensive Systems: A Practitioners Guide. Software Engineering. CRC Press SE 501 Dr. Basit Qureshi

4 SDLC Continued SE 501 Dr. Basit Qureshi

5 SDLC continued Last week Ad Hoc Classical (Water fall) Prototype RAD
Incremental Spiral WinWin V model Chaos SE 501 Dr. Basit Qureshi

6 SDLC: More recent Agile RUP TSP ACDM SE 501 Dr. Basit Qureshi

7 SDLC: More recent SE 501 Dr. Basit Qureshi

8 Agile methods “Marked by ready ability to move with quick easy grace”
Webster Dictionary: “Marked by ready ability to move with quick easy grace” As applied to Software Development: Cockburn “Ability to change development in response to changing requirements” SE 501 Dr. Basit Qureshi

9 Agile methods The Agile Manifesto [http://agilemanifesto.org/] “A method of software development that aims for customer satisfaction through early and continuous delivery of useful software components” SE 501 Dr. Basit Qureshi

10 Chapter 3 Agile software development
Agile methods Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast –changing requirement and it is practically impossible to produce a set of stable software requirements Software has to evolve quickly to reflect changing business needs. Rapid software development Specification, design and implementation are inter-leaved System is developed as a series of versions with stakeholders involved in version evaluation User interfaces are often developed using an IDE and graphical toolset. Chapter 3 Agile software development

11 SE 501 Dr. Basit Qureshi

12 Chapter 3 Agile software development
Agile methods Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: Focus on the code rather than the design Are based on an iterative approach to software development Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework. Chapter 3 Agile software development

13 Chapter 3 Agile software development
Agile manifesto We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value: 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, whilethere is value in the items on 
the right, we value the items on the left more. Chapter 3 Agile software development

14 The principles of agile methods
Description Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system. Chapter 3 Agile software development

15 Agile method applicability
Product development where a software company is developing a small or medium-sized product for sale. Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software. Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems. Chapter 3 Agile software development

16 Plan-driven and agile development
Plan-driven development A plan-driven approach to software engineering is based around 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 occurs within activities. Agile development Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process. Chapter 3 Agile software development

17 Plan-driven and agile specification
Chapter 3 Agile software development

18 Agile methods XP Scrum Crystal Feature Driven Open Source
Software Develop RUP (AUP) Dynamic Systems Develop Method Adaptive Software Develop Synch and stabilize SE 501 Dr. Basit Qureshi

19 Agile methods Common characteristics
Individuals and Interactions over Processes and Tools Team dynamics experience mix, team size Physical workspace, communality, meetings Working Software over Comprehensive Documentation Code primary artifact Iterative (subscription) Value to the customer QA inherent SE 501 Dr. Basit Qureshi

20 Agile methods Customer Collaboration over Contract Negotiation
Customer Onsite (Involved/Knowledgeable) Requirements Centric Rapid Return of Perceived Value Customer Expectation Management Responding to Change over Following a Plan Developer / Customer Team Emergent Requirements Short Iterations Smaller changes Adaptation SE 501 Dr. Basit Qureshi

21 Why Agile methods What agile proponents say: Flexibility
Market Changes Technology Changes (Moore’s Law) Unclear Requirements More coding, less paper-work Higher quality, quicker SE 501 Dr. Basit Qureshi

22 Why Agile methods What the opponents say: No plan, no structure
Architecture? Easily derailed Inefficient use of developers pair programming No documentation Unrealistic customer involvement SE 501 Dr. Basit Qureshi

23 Why Agile methods “More than 2/3’s of all corporate IT organizations will use some form of agile software development process in the next 18 months.” Giga Information Group Inc., 2002 Cutter Report “Agile vs. Heavy” Use is increasing SE 501 Dr. Basit Qureshi

24 Why Agile methods And now.. Chaos Report published in 2012.
49% of businesses say most of their company is using Agile development 52 % of customers are happy or very happy with Agile projects The number of those who plan to implement agile development in future projects has increased from 59% in % in 2012. The most popular Agile method used is Scrum (52%) SE 501 Dr. Basit Qureshi

25 Weakness of Agile methods
Communication is critical Projects with Non- Decomposability / Coupled Functionality Scalability Reliance on Corporate Knowledge – Document at End Maintenance Long Life Cycle SE 501 Dr. Basit Qureshi

26 Weakness of Agile methods
Centralized management control “Big” Specifications Required Documentation Safety Critical Non-flexible work environment Fixed Price and Scope SE 501 Dr. Basit Qureshi

27 Agile methods Agile center piece: Coding Emphasizing what we do best
What we prefer to do Lack of formal design, architecture Lack of documentation But makes you think about what is important SE 501 Dr. Basit Qureshi

28 Agile methods Some Agile methods users Microsoft Thoughtworks
Valtech Technologies RADsoft Boeing < 5 on a team Al Elm Information Security Arabian Electronics Co SE 501 Dr. Basit Qureshi

29 RUP SE 501 Dr. Basit Qureshi

30 RUP The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003 RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs SE 501 Dr. Basit Qureshi

31 RUP Four project lifecycle phases Inception Phase: Elaboration Phase:
Stakeholders, Requirements understanding, cost/schedule estimates, architectural prototype, compare actual expenditures versus planned expenditures. Elaboration Phase: Most of the use-case descriptions are developed (80%), software architecture, development plan for the overall project, Business case and risk list. Construction Phase Build the software system, Software Release. Transition Phase Transit from development to production, training, testing SE 501 Dr. Basit Qureshi

32 RUP Outline – Phases vs iterations
SE 501 Dr. Basit Qureshi

33 RUP Strengths: Structured Iterative
Use Cases – strong concept, used widely Tied to UML Robust tool support Tailor-able / Scalable “Agile” ? SE 501 Dr. Basit Qureshi

34 RUP Weaknesses Use cases – do they work for all projects?
Learning curve Tied to tools UML Architecture? Non functional requirements Quality Attributes? SE 501 Dr. Basit Qureshi

35 RUP Center piece: Model analysis
Modeling allows stakeholders to understand the problem Great for functionality Not so good for Quality Attributes SE 501 Dr. Basit Qureshi

36 PSP / TSP Personal Software Process (PSP) 1989’
structured software development process that is intended to help software engineers understand and improve their performance, by using a "disciplined, data-driven procedure" Team Software Process (TSP) 2000’ designed to help teams of managers and engineers organize projects and produce software products The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s SE 501 Dr. Basit Qureshi

37 Prevent defects earlier
PSP / TSP Builds on Personal Software Process (Pre-requisite) Prevent defects earlier Defined framework - Scripted Cyclic, iterative Standard measures for quality and performance Precise data collection- on almost everything Established Roles Discipline and guidance Post Mortem each cycle – find the problems CMM… SE 501 Dr. Basit Qureshi

38 PSP / TSP Every cycle produces an artifact
A Team Software Process Cycle: 1- Strategy 2- Plan 3- Requirements 4- Design 5- Implementation 6- Test 7- Postmortem SE 501 Dr. Basit Qureshi

39 PSP / TSP TSP is document driven The “Good” of TSP The “other”
Structured Scripted Highly defined New teams, or ones with no structure SEI has data on about 20 projects The “other” Possible problems with change/flexibility Requirements? Documentation SE 501 Dr. Basit Qureshi

40 PSP / TSP TSP centerpiece: Data Collection
Only source of “bugs” is humans Developers on the whole are unstructured and tend towards “hacking” Need to identify source and mitigate problem SE 501 Dr. Basit Qureshi

41 PSP / TSP users U. S. Navy Microsoft Xerox Bechtel – Bettis
Advance Information Systems SE 501 Dr. Basit Qureshi

42 ACDM Architecture Centric Development Method
ACDM is an iterative development method iteratively refines and reviews the architecture until it is deemed fit for the purpose permits iteration in the production of the elements/system/products ACDM has 7 stages in the development method. ACDM proposed by Anthony J. Lattanze of the of SEI at CMU, 2009. SE 501 Dr. Basit Qureshi

43 ACDM SE 501 Dr. Basit Qureshi

44 ACDM Strengths: Product and Architectural focus.
Agile and relatively lightweight. Structured but flexible and tailorable. Iterative. Derived from Studio Practitioners. Provides guidance for roles, activities, and artifacts. Derives requirements (architectural drivers) from business drivers. SE 501 Dr. Basit Qureshi

45 ACDM Weaknesses: Not a lot of industrial experience or data.
Unclear how well ACDM scales up to large projects. Still maturing. No tool support or templates. Depends upon a relatively good understanding of architectural concepts. SE 501 Dr. Basit Qureshi

46 ACDM Centerpiece: Architecture
Complexity/scope driving need for more abstraction Key to describing and predicting quality attributes Lots of development and research Easily misunderstood SE 501 Dr. Basit Qureshi

47 Choosing suitable sdlc
SE 501 Dr. Basit Qureshi

48 Choosing suitable SDLC
Looking for a recipe… . There is no silver bullet Do not tailor your project to a process, instead tailor the “right process” Supermarket shopping Do not pick all the “best” techniques within processes and mix them together But you can use some in tailoring SE 501 Dr. Basit Qureshi

49 Choosing suitable SDLC
SE 501 Dr. Basit Qureshi

50 Choosing suitable SDLC
“Choose Your Weapon Wisely” Justin Rockwood 2003. Describes a weighted matrix model Weakness Push Strength Compares suitability of 5 methods RUP MS Synch and Stabilize TSP XP Scrum SE 501 Dr. Basit Qureshi

51 Choosing suitable SDLC
Weighted score for following project characteristics Average team size and total developers Product size and complexity Developer competence and experience “Hacker sentiment” Management style Organization wide processes New process adoption Type of product Requirements stability Requirements traceability SE 501 Dr. Basit Qureshi

52 Choosing suitable SDLC
Example of determining total number of developers SE 501 Dr. Basit Qureshi

53 Choosing suitable SDLC
Example of determining type of project SE 501 Dr. Basit Qureshi

54 Choosing suitable SDLC
Add up scores 11 project areas But… Not definitive – Start point for research General direction Tied scores, or little variation Lower scoring method may still be suitable Not complete, needs more work Weighting some criteria more than others? Defining other processes SE 501 Dr. Basit Qureshi

55 Choosing suitable SDLC
Balancing…! SE 501 Dr. Basit Qureshi

56 Choosing suitable SDLC
Personnel discriminator…! SE 501 Dr. Basit Qureshi

57 Choosing suitable SDLC
Apply discriminators Criticality – Measured by loss, annoyance to $ to life Size – gradient on this? Cultural – chaos or planned Dynamism- volatility of requirements Closer to center promotes Agile SE 501 Dr. Basit Qureshi

58 Choosing suitable SDLC
The methods shown just point to the right direction and are not absolute answers Analysis of current method Plan any adoption of a new method ROI is important As is cost to benefit All methods work for the right Project Team Organization (But some may be better) SE 501 Dr. Basit Qureshi

59 Summary Continued SDLCs Choosing the appropriate SDLC for project
Assignment #2: Group work SE 501 Dr. Basit Qureshi


Download ppt "SE 501 Software Development Processes"

Similar presentations


Ads by Google