The Software Development Process Explained
•Transferir como PPT, PDF•
3 gostaram•3,794 visualizações
Software Development process. What’s Wrong with these Antiquated Life Cycle Models?
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (19)
Semelhante a The Software Development Process Explained
Semelhante a The Software Development Process Explained (20)
Mais de Cesar Augusto Nogueira
Mais de Cesar Augusto Nogueira (20)
Último
Último (20)
The Software Development Process Explained
- 1. The Software Development Process "It is better not to proceed at all, than to proceed without method." --Descartes "Stop the life cycle--I want to get off" -- Barry Boehm
- 2. A Software Development Process Organizes the Activities of Software Development Gather Requirements Design System Test Unit TestIm plem ent Rework Correct Mistakes Review CreatePrototype ManageRisks Integrate Developing software without a defined process is chaotic and inefficient Following a defined process makes software development more orderly, predictable and repeatable . . . . . .
- 3. Software Process • A software process is more detailed than a life cycle model. • A Software process says who does what when. • A software process includes: – Roles – Workflows – Procedures – Standards – Templates
- 4. Resistance to Process • Some people view following a process as an unnecessary tax on productivity. That is, they view the time devoted to following a process as taking away from time that could otherwise be spent on “productive work” without any otherwise appreciable affects on the development process [McConnell 1998].
- 5. The Reality • A group not following a defined process might show more productivity at the start, but rework due to poor development practices will quickly outweigh any time saved by not following a process [McConnell 1998]. Too little process in the beginning often leads to too much process towards the end The overhead of following a process decreases with time
- 6. When Bad Process Happens to Good People • Some processes are rigid and bureaucratic; don’t use these • Some people abuse process for their own agenda (i.e. feed their desire to have power and control, block changes or developments they don’t agree with); don’t allow these people to have authority over the process
- 7. Characteristics of a Good Process • A good software process is: – Repeatable – a process is repeatable if it can be performed again on a new project? If the process isn’t documented, it probably isn’t repeatable. – Predictable – Organizations like predictability. It means they know what to expect when repeating the process. – Adaptable - the process can be tailored for the unique aspects of a project. In general, the more adapted a process is, the less predictable it will be. – Learnable – – Measurable – Measurability is important for tracking, control, visibility and improvability. – Improvable
- 8. Terminology • Software Life Cycle – The high-level phases or stages that software goes through from the moment it is conceptualized until the last version is removed from the last machine. The software life cycle consists of new development followed by a number of maintenance updates and finally retirement. [IEEE 610] • Software Development Life Cycle (SDLC) – The sequence of phases a project goes through from start to finish. The standard phases of the SDLC are: requirements specification, analysis, design, implementation and test. Inception and delivery may also be included. Note, these phases are not necessarily sequential. They may overlap or be performed iteratively. The SDLC is applied to new development and maintenance updates. [IEEE 610]
- 9. Terminology [cont] • Software Life Cycle Models (aka Software Process Models) – abstract models that describe a class of development approaches with similar characteristics. Some of the criteria used to distinguish software life cycle models are: timing between phases, entry and exit criteria between phases and the artifacts created during each phase. Examples include: Waterfall, Spiral, Rapid Prototyping, Incremental Development, etc.
- 10. Terminology [cont] • Software Process, Methods, and Methodologies
- 11. Phase Names vs. Activity Names • Is requirements (or design, or coding, or etc.) a phase or an activity? • Terms such as requirements, design, coding, etc. are used to characterize a phase (adjective) and also an activity (verb/adverb) that might occur during one or more phases. • It’s important to distinguish between a label given to a phase and the activity that occurs during that phase.
- 12. Phase Names vs. Activity Names [cont] • The label on a phase is descriptive of the dominate activity performed during that phase. It becomes confusing when there isn’t a one-to-one correspondence between phase name and activity within that phase.
- 13. Phase Names vs. Activity Names [cont] • The Rational Unified Process (RUP) avoids any ambiguity/confusion by using phase names that can’t be confused with the activities that might take place during a phase. • The names are also more appropriate because they better match the milestones and deliverable of the phases.
- 15. Software Life Cycle Models • Abstract models that define a few broad types of software development processes • Life cycle models specify: – Major phases including milestones and deliverables – Timing between each phase – Entry and exit criteria for each phase • Life cycle models are a starting point for project management
- 16. Antiquated Software Life Cycle Models • Code-and-Fix Development • Waterfall
- 17. Code-and-Fix Development • Not a viable development model for most projects. • Code-and-Fix is to software development as dog paddling is to swimming.
- 18. Waterfall • Sequential stages with little or no backtracking
- 19. The Waterfall Model Illustrated
- 20. Risk Profile of Waterfall Project • When following the waterfall process model risks aren’t resolved until late in the development cycle.
- 21. What’s Wrong with these Antiquated Life Cycle Models? • Code-and-fix lacks discipline and is inefficient • Waterfall, although appropriate for some projects, doesn’t fit well in today’s environment
- 22. Iterative and Incremental • A characteristic of modern life cycle models. The product evolves incrementally over a series of iterations.
- 23. Benefits of an Iterative and Incremental Approach • More appropriate for applications with emergent requirements. For many UI applications, requirements aren’t well-known form the start but rather emerge over time based on experience with early increments and prototypes. • Incremental functionality is a more accurate measure of progress than paper deliverables. This provides better visibility into project status. • Manages risks better (technical risks with architecture and programming and project risks with meeting schedule and budget targets)
- 24. Modern Software Life Cycle Models • Spiral • Staged • Evolutionary Prototyping • Evolutionary Delivery
- 25. Spiral
- 26. Staged • Requirements and planning occur up-front but product is developed and delivered over a series of iterations.
- 27. Evolutionary Prototyping • The contents of each iteration is driven by feedback from previous iterations.
- 28. Evolutionary Delivery • The middle ground. Considerable planning and product definition occur up-front, but the content of each iteration is also influenced by feedback from previous iterations.
- 29. Guidelines for Selecting a Lifecycle Model
- 30. Other forms of prototyping • Evolutionary prototyping is a life cycle model—a way of organizing the activities of software development. • Prototyping can also be used selectively on any project as a technique for buying information. • Developing the wrong product can be costly. Sometimes it pays to invest in an early quick-and-dirty prototype to explore requirements and resolve technical risks before committing to expensive production-quality development. • With evolutionary prototyping the product increment is expected to evolve into the eventual production system. With other forms of prototyping the software created may or may not be a part of the eventual implementation. If it is a paper prototype, definitely not. If the prototype is a series of screens created with an IDE, the screens may very well end up in the final product.
- 31. Options for creating a prototype • Paper mock-ups are perhaps the simplest form of prototyping. A paper mock-up is a stack of fabricated screen shots created by hand or with the help of a graphics editing or desktop publishing system. There should be a page for every view and/or state of the application you want to test. The experimenter simulates the behavior of the application by showing different pages at different times in reaction to the test subject’s actions [Nielson 93]. • Most integrated development environments (IDE’s) come with tools for creating UI’s by dragging and dropping UI elements on a canvas. You don’t have to implement the behavior behind each screen to have a useful prototype. A small amount of control logic may be helpful to move from screen to screen. • If your target language isn’t conducive to prototyping, you can create the prototype with a prototyping tool or high level (possibly scripting) language that has better support for rapid application development.
- 32. Horizontal and vertical prototyping • A prototype represents a subset of the eventual system functionality. There are two dimensions along which a prototype can vary.
- 33. Horizontal and vertical prototyping • A horizontal prototype is one that includes many features but little functionality behind each one. Think of a movie set with store front facades but no actual stores behind them. Horizontal prototyping helps to clarify requirements and evaluate usability. • A vertical prototype is one that implements only a few features but each one in depth. Vertical prototyping can be used to explore various design and implementation options.
- 34. Throwaway Prototyping • When code is written quickly without regard for sound engineering practices, it is poor bases on which to build and should be thrown out once the goals for creating the prototype have been accomplished. This form of prototyping is appropriately called throwaway prototyping.
- 35. Anchoring the Software Process • Intuitively—Requirements, Architecture, Design, Code—seem like good milestones for marking progress during a software project, but in practice they don’t work so well. • Rarely do these products evolve sequentially as discrete entities. • More commonly, these artifacts evolve slowly in parallel. This makes them poor milestones for anchoring a software development process
- 36. Anchoring the Software Process - 2• Barry Boehm proposes an alternative set of milestones that are more appropriate for iterative development [IEEE Software July 1996]: – Life cycle objectives (Major requirements, major scenarios of operation, candidate architecture, and top-level plan are known) – Life cycle architecture (Most requirements and scenarios of operations are known, validated system architecture) – Initial operational capability (The product is ready for transition to its production environment.
Notas do Editor
- A software process organizes and prescribes the activities necessary to write software . Tbd: add “Define problem” There isn't one best process for writing software. The process that an individual or organization selects and follows should be selected for and tailored to the specific characteristics of the project, the organization’s culture and the abilities and preferences of the people involved . Software process is a guide that leads/instructs less experienced teams but also is flexible enough to be tailored by more experienced teams. A good process will raise the productivity of less experienced team members without impeding the work/progress of more experienced team members. “ I expect that we will end up with a number of these methodologies with overlapping boundary conditions. We will need to choose which one best matches our profile. We’ll start with one of these then rapidly tune it to a particular circumstance. Certainly, anything you pick will only be a starting point and then you tune it to what you need it to be. Methodologies can also give you good practice ideas.”
- A software process “establishes the technical and management framework for applying methods, tools, and people to the s/w task.” I could add a slide comparing characteristics of life cycle models and processes. Life cycle models: major phases, timing between each phase, entry and exit criteria for each phase (exit criteria includes milestones and deliverables at the end of each phase). Processes include more detail: roles, specific tasks, measures, entry and exit criteria for major steps [psp: A self-improvement process for software engineers]. Good introduction to s/w processes in [psp: A self-improvement process for software engineers, p 12].
- “ interferes with creativity” “ Bureaucratic and regimented” “ Hinders agility in fast-moving markets” There once was a time (70’s) when some people seriously believed not wearing a seatbelt was safer because you would be thrown from the car which would give you a better chance of survival.
- Groups that don’t start out following a defined process often find themselves adding process later in the project in reaction to problems. As the size and complexity of a project grows, the importance of following a defined process grows proportionally.
- Process A has an average productivity of X but is predictable; Process B has an average productivity of X + 1 but is less predictable. Which one would most businesses prefer? A good process is repeatable and predictable. This improves the ability to estimate work. Don’t confuse repeatability with rigidity . To the extent the next project deviates from the previous project, the process may need to be modified. Question: Consider a high performance team that has lots of experience working together that generally follows their own internalized process. How well does this approach to process measure up to these characteristics of a good process?
- Software Lifecycle: Requirements, specification, design, implementation, testing, deployment, maintenance and evolution, replacement or retirement. Words derive their meaning from usage and context. When there are subtle differences between concepts in a single context the same words are not always used in a consistent way. This is a frequent problem in the emerging field of software technology especially when it comes to defining the concepts around the software development process. It’s impossible to give a definitive definition of these terms because they aren’t used consistently. I’ll do the next best thing which is to define how I intend to use them. As much as possible, these definitions are consistent with the way these terms are used in practice.
- A process is a series of steps for turning inputs into outputs. In the case of software it’s a sequence of steps for turning customer requirements into finished product. In general software development is too complex to be described by a detailed prescriptive process, instead we have methodologies. A software methodology is a collection of processes, methods, techniques, standards, values etc. used to develop software. In short, a methodology is a group of methods unified by a philosophy. (TBD: Add “workflows”) Example methods: OOP, CRC cards, refactoring, etc.
- Big-M or Capital-M Methodology is not consistently defined. Some authors (Cockburn July 2000 IEEE Software) use it to distinguish between a full methodology (I.e. XP) and a collection of related methods and techniques (I.e. OOP). Other authors (Rosenberg) use it to distinguish between Methodologies that advocate strict adherence (like a religion) and methodologies which can be selectively tailored for unique project needs. Milton friedman use to say he was a libertarian with a small “l” meaning he wasn’t a devoted member of the party but believed strongly in it’s ideals.
- Waterfall is considered antiquated. It has largely been discredited.
- Image from: http://software-document.blogspot.com/2011/01/what-is-rational-unified-process-and.html Activities aren’t confined to one phase. Activities overlap and interact.
- Life cycle models are also used to express and promote philosophies of development.
- [Not really a model. Code and fix is to software development as dog paddling is to swimming. This analogy works on several levels. If you throw someone who can't swim into a pool they are likely to dog paddle instinctively . There are much more effective and efficient swimming strokes but they take training and experience. They might make it across the pool but are likely to be exhausted and in no mood for another swim. If you throw an untrained inexperienced person into a software development project there inclination will be to resort to code and fix. It might get the job done but it's certainly not the most efficient approach. Also, just as some individuals learning to swim sometimes panic and revert back to dog paddling, a project can sometimes revert back to code and fix at the first sign of trouble following a defined process. At the risk of overstretching the analogy, the best swimming stroke and the best process model depends on the individual and environment .] Might seem odd and unnatural at first (going through the motions until it becomes part of muscle memory). The code-and-fix model is probably the most-derided but most-used model of them all. (If you count the thousands of small software programs created each day.) A process following the code-and-fix model starts with just enough requirements analysis to begin coding. Once something is working it is reworked until it meets all of the requirements of the project. This may require repeated cycles of requirements analysis, design and coding. [I could be a little less tolerant] For all the ridicule it has received the code-and-fix model is a reasonable choice for some programs. If you are building a program for your personal use (you are the sole source of requirements), it is a small simple program, and you don't plan on extending the program in the future your best choice might be a process that follows the code-and-fix model. The problem with the code-and-fix model occurs when it is applied to a project that doesn't meet the special criteria mentioned above. The reason it fails for projects that don't meet the criteria above is because it causes too much rework. Rework not only takes time but can also destroy the structure of the system. Code and fix has persisted for so long probably because of its intuitive nature. It’s generally tolerated because proper methods aren’t well understood or universally accepted. Some developers have never been exposed to alternatives. Others have been exposed but don’t see any clear consensus on how best to develop software so aren’t encouraged to move beyond intuitive methods.
- The pure waterfall model is probably the most familiar software development lifecycle model yet least used. It’s familiar because it is orderly and intuitively easy to understand. It’s least used because most of software development involves unfamiliar problems and technology. The waterfall model doesn’t deal with uncertainty well ( little or no opportunity for incorporating feedback ). It did include backtracking and prototyping as originally proposed [Royce 1970] but most consider waterfall to refer to a sequential development process with no backtracking.
- [Source Unknown]
- Good ref: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
- The term iterative and incremental is sometime used to refer to a life cycle model. The terms are so general that it’s better to think of iterative and incremental as characteristics of life cycle models. Benefits: o On of the advantages of iterative development is that it provides visible signs of progress. This is good for progress tracking and team morale. o Gets partial functionality into the hands of users early Process feedback examples: o validate the accuracy of early estimates o
- Also: manage complexity. Iteration is a powerful tool for managing complexity . It’s a divide and conquer process. It’s usually easier to evolve the artifacts of software development in parallel. Working on down-stream artifacts often helps in the completion of up-stream artifacts. For example, when doing object modeling you might model the objects in the problem domain before writing use cases. Writing use cases will invariable lead to forgotten domain objects. It’s rare for complex intellectual artifacts to be perfected during one inspirational moment. Most evolve over a cycle of continuous refinement.
- The Spiral model improves on the models that preceded it because it is a risk-driven rather than document- or code-driven model [Boehm 1988]. The spiral model deals with risks early in the software life-cycle when there is more time to deal with problems the risks may cause and before there is significant amount of work completed which can be affected. First real use of iteration. Needed to address software systems with emergent requirements and users that couldn’t properly articulate their requirements without something tangible to evaluate. A loop around the circle represents one phase in the process. Each phase has 4 parts: 1. (upper left-hand corner) Determine objectives alternatives and constraints. 2. Evaluate alternatives, assess risks, resolve risks 3. Develop and validate. Any development model may be used during this step. 4. Plan the next phase
- Like waterfall but the product is delivered over a sequence of iterations. The customer gets value from certain features early but no prevision is made for incorporating feedback from previous iterations. It provides a stable environment for development but little or no opportunity to incorporate feedback.
- In pure evolutionary prototyping no attempt is made at planning or product definition beyond the immediate iteration. Don’t be mislead by the term “prototyping”. With evolutionary prototyping the product is built to production standards of quality. It’s prototyping in the sense that early versions of the software are being provided to users in order to discover requirements that haven’t been thought of yet. Potentially releasable . XP follows this model with the contents of each iteration decided by the customer prior to the start of each iteration. To avoid expensive rework, a prerequisite for using this model is: All of the critical requirements—those likely to effect the architecture of the solution—are well-understood and not likely to change based on feedback from early iterations. OR B) There is reasonable expectations that techniques such as refactoring can be used to evolve the architecture in the event there are new or changing architecturally significant requirements. Before you can start evolutionary prototyping, critical requirements must be understood. If they aren’t, you can use throwaway prototyping in order to convert poorly understood requirements into well-understood requirements. Strength: uncover previously unknown requirements. Trying to discover requirements critical to the selection of the software’s architecture.
- In most cases a majority of planning and requirements definition is performed up-front and stabilizes quickly.
- Prototyping can also be a handy technique for buying information. A more general use of prototyping is a technique Prototyping can also be used more selectively/surgically as a technique for buying information. Throwaway prototyping is a technique that can be used throughout the software life cycle no matter what model is being used to organize the activities of development. “ simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.” “ obtain feedback from the users early in the project”
- Prototypical Prototypes
- From page 94 in Usability Engineering [Nielsen] He also discusses scenario prototyping. (Consider adding a def of this)
- Older definition. Even though Advances in Computers was published after Usability Engineering more people reference Nielsens definition.
- The first decision when building a prototype is to decide what subset of functionality to include in the prototype. The decision is driven by the goals of the prototype. More generally, a prototype represents some subset of total system features and functionality.
- [What] o A throwaway prototype is an early mock-up of a software system developed/created quickly in order to clarify requirements and experiment with design and implementation options. o The prototype is created quickly without regard for maintainability and robustness. It would be difficult to maintain or enhance. o A throwaway prototype is used to explore requirements and experiment with various design alternatives. Because it is created for timely feedback without concern for qualities that will make it robust and sustainable, it is discarded once information is obtained. o The creation of a prototype is a standard engineering practice. Car manufactures routinely build prototypes in order to elicit customer feedback and better understand the car they intend to build. The production line needed to manufacture a product is expensive to build and difficult to change. Manufactures create prototypes to minimize the risks associated with building the wrong product. Software engineers create prototypes in order to minimize risk of wasted effort associated with building the wrong product. Writing production-quality code is expensive. o Building a prototype or mock-up of a product before committing to an expensive build process is a common engineering practice. [What is the relationship between throwaway prototyping and evolutionary prototyping?] o They are two really very different things. Evolutionary prototyping is a development approach or lifecycle model and throwaway prototyping is a technique or practice that can be selectively/narrowed applied within the context of any lifecycle model. For example, the spiral model suggests creating prototypes in order to resolve risks during each iteration. They are really apples and oranges. [Why/Benefits] o Provides insights into alternative design approaches. o Gain experience with the technologies needed to implement certain features. This experience helps forms concepts useful during design also. The use of prototypes to resolve technical risks and improve design are often overlooked. Explore alternative designs. Compare design and implementation options. Helps programmers understand implementation options and form concepts useful during design conceptualization. o Validate API’s and other dependent services are working as expected. o Tool for more effective communication between developers and users. Sometimes clients aren’t sure what they want until they have a chance to interact with working software. Users need actual experience with the proposed software system before they can provide a complete and accurate set of requirements. Allows clients to better articulate what behavior is needed from the software. o The introduction of software into an environment changes that environment which can lead to new requirements. Introducing a throwaway prototype is one way to identify these emergent requirements early in the software development lifecycle. You want to identify them early so they can be analyzed and prioritized along with existing requirements. o Creating a throwaway prototype addresses s/w eng principles: “do it twice” and “plan to throw one away”. o It’s a great way to get the user involved. Most users don’t have the time or patience to read through hundreds of pages of specifications. Reacting to software is much easier. They are also likely to get the feeling their needs are being addressed. o The prototype can server as partial system specification. Users would much rather validate requirements by working with a prototype rather than read 100’s of pages of documentation. [When to apply] o When requirements are unknown or not well-understood, especially requirements likely to have a strong impact on the architecture. It’s not advisable to start writing production code until the architecture is stabilized. o When using unfamiliar implementation technologies. Reduces technical risks which helps with project estimating and planning. On a more abstract level, experimenting with implementation technologies help establish concepts useful for positing an architecture. [How to apply] o Start with a clear definition of the purpose and scope of the prototype. o Prototypes don’t have to be elaborate. Much can be learned by simple paper prototypes or simulated screen sequence. o When building a throwaway prototype, select a development approach, such as code-and-fix, that is optimized for speed. The code doesn’t have to be robust, doesn’t have to be well-designed or maintainable and doesn’t have to include error checking and exception handling code. You want to get something in the hands of users quickly and react quickly to there suggestions for changes. Build the prototype as quickly as possible. o Focus on areas that are poorly understood. There is little value in prototyping well-understood requirements and implementation technologies. [Potential problems or pitfalls associated with creating a throwaway prototype] o The throwaway prototype might not get thrown away. The outwardly appearance of the prototype fails to reflect the shabby nature of its construct. Nobody would recommend a western set façade be used as an actual place of business, but managers routinely press to have the “throwaway” prototype messaged into the finaly working product. It’s often not simply of adding error checking and exceptions. Often the software isn’t robust and lacks the structure needed to make it maintainable and extendable. (how to deal with this problem) Get a firm commitment to actually discard the prototype once the reasons for creating it are satisfied. Option 2: code it in a different language so it has to be rewritten. You can’t retrofit quality. o Users may develop unrealistic expectations regarding the time it takes to deliver the final production-quality system. Unless they are warned against it, most users will underestimate the amount of effort it takes to convert a throwaway prototype into production-quality software. The rate at which features can be added to a throwaway prototype can mislead clients (and managers) into expecting the same rate of progress with the production version of the software. This can lead to unrealistic expectations on the part of end users and under estimation on the part of project managers. o Another problem with failing to make a clear distinction between the prototype and the production system to be delivered in the future is expecting too little. Users might assume shortcomings in the prototype will be carried over into the actual production system. (How to deal with it.) Limit access to prototype to controlled settings where technical staff can explain the prototyping process and manage expectations. o [Gordon 94, Rapid Prototyping: Lessons Learned] warns, “…developers should not oversell the prototype in an effort to impress the customer.” o Most of these problems and pitfalls can be avoided by making a clear distinction between the prototype and the final delivered system and by carefully defining upfront the purpose and scope of the prototype [Gordon 94, Rapid Prototyping: Lessons Learned].
- You could define a 4 th milestone which is “project complete”. These are the major milestones used in the Rational Unified Process.