Specialized process model 

There are 4 types of Specialized process model :

1.5 SPECIALIZED PROCESS MODELS.

 Special process models take on many of the characteristics of one or more of the conventional models. However, specialized models tend to be applied when a narrowly defined software engineering approach is chosen.


 1.5.1 COMPONENT-BASED DEVELOPMENT. Commercial off-the-shelf (COST) software components, developed by vendors who offer them as products, can be used when software is to be built. These components provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software. The component-based development model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the model composes applications from prepackaged software components. Modeling and construction activities begin with the identification of candidate components. These components can be designed as either conventional software modules or object-oriented classes or packages of classes. Regardless of the technology that is used to create the components, the component-based development model incorporates the following steps (implemented using an evolutionary approach):

• Available component-based products are researched and evaluated for the application domain in question. http://wikistudent.ws/Unisa
• Component integration issues are considered.
• A software architecture is designed to accommodate the components.
 • Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality. The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. Based on studies of reusability component-based development can lead to reduction in development cycle time, reduction in project cost and increase in productivity. Although these results are a function of the robustness of the component library, there is little question that the component-based development model provides significant advantages for software engineers.

 1.5.2 THE FORMAL METHODS MODEL. The formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying rigorous, mathematical notation. A variation on this approach is called clean-room software engineering. When formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, not through ad hoc review, but through the application of mathematical analysis. When formal methods are used during design, they serve as a basis for program verification and therefore enable the software engineer to discover and correct errors that might otherwise go undetected. Although not a mainstream approach, the formal methods model offers the promise of defect-free software. Yet, concern about its applicability in a business environment has been voiced:
• The development of formal models is currently quite time-consuming and expensive.
• Because few software developers have the necessary background to apply formal methods, extensive training is required.
 • It is difficult to use the model as a communication mechanism for technically unsophisticated customers.

 1.5.3 ASPECT-ORIENTED SOFTWARE DEVELOPMENT.

Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions and information content. These localized software characteristics are modeled as components and then constructed within the context of a system architecture. As modern computer-based systems become more sophisticated and complex, certain concerns, customer required properties or areas of technical interest, span the entire architecture. Some concerns are high-level properties of a system; others affect functions or are systemic. When concerns cut across multiple system functions, features, and information they are often referred to as crosscutting concerns. Aspectual requirements define those crosscutting concerns that have impact across the software architecture. Aspects are mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concerns. Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming (AOP), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects. http://wikistudent.ws/Unisa A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will adopt characteristics of both the spiral and concurrent process models. The evolutionary nature of the spiral is appropriate as aspects are identified and then constructed. The parallel nature of concurrent development is essential because aspects are engineered independently of localized software components and yet, aspects have a direct impact on these components.

 1.6 THE UNIFIED PROCESS.

In some ways the unified process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development. The unified process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system. It emphasizes the important role of software architecture and helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development.

1.1 PRESCRIPTIVE MODELS OR CONVENTIONAL MODELS. Every software engineering organization should describe a unique set of framework activities for the software processes it adopts. It should populate each framework activity with a set of software engineering actions, and define each action in terms of a task set that identifies the work (and work products) to be accomplished to meet the development goals. It should then adapt the resultant process model to accommodate the specific nature of each project, the people who will do the work and the environment in which the work will be conducted. Regardless of the process model that is selected, software engineers have traditionally chosen a generic process framework that encompasses the following framework activities:
• Communication – This framework activity involves heavy communication and collaboration with the customer (and other stakeholders) and encompasses requirements gathering and related activities. • Planning – This activity establishes a plan for the software engineering work that follows. It describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.
 • Modeling – this activity encompasses the creation of models that allow the developer and the customer to better understand software requirements and the design that will achieve those requirements.
 • Construction – This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.
• Deployment – The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation. We call these models prescriptive because they prescribe a set of process elements namely framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project. Each process model also prescribes a workflow that is, the manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activities, but each applies a different emphasis to these activities and defines a workflow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner.

Software developing models

1.2 THE WATERFALL MODEL. 

There are times when requirements of a problem are reasonably well understood, when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made. It may also occur in a limited number of new development efforts, but only when requirements are well-defined and reasonably stable. The waterfall model, sometimes called the classic life cycle, suggest a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in on-going support of the completed software. http://wikistudent.ws/Unisa The waterfall model is the oldest paradigm for software engineering. However, over the past two decades, criticism of this process model has caused even ardent supporters to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are: • Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. • It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. • The customer must have patience. A working version of the program will not be available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous. In an interesting analysis of actual projects it was found that the linear nature of the waterfall model leads to “blocking states” in which some project team members must wait for other members of the team to compete dependent tasks. In fact, the time spent waiting can exceed the time spent on productive work. The blocking state tends to be more prevalent at the beginning and end of a linear sequential process. Today, software work is fast-paced and subject to a never-ending stream of changes (to features, functions and information content). The waterfall model is often inappropriate for such work. However, it can serve as a useful process model in situations where requirements are fixed and work is to proceed to completion in a linear manner.


1.3 INCREMENTAL PROCESS MODEL. 

There are many situations in which initial software requirements are reasonably well-defined, but the overall scope of the development effort precludes a purely linear process. In addition, there may be a compelling need to provide a limited set of software functionality to users quickly and then refine and expand on that functionality in later software releases. In such cases, a process model that is designed to produce the software in increments is chosen.

1.3.1 THE INCREMENTAL MODEL.

The incremental model combines elements of the waterfall model applied in an iterative fashion. The incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable increments of the software. It should be noted that the process flow for any increment may incorporate the prototyping paradigm. When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed evaluation). As a result of use and or evaluation, a plan is developed for the next increment. The plan addresses the modification to the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are “stripped down” versions of the final product, but they do provide capability that serves the user and also provides a platform for evaluation by the user. http://wikistudent.ws/Unisa Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, additional staff (if required) can be added to the implement of the next increment. In addition, increments can be planned to manage technical risks.

1.3.2 THE RAD MODEL.

 Rapid application development (RAD) is an incremental software process model that emphasizes a short development cycle. The RAD model is a high-speed adaptation of the waterfall model, in which rapid development is achieved by using a component based construction approach. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within a very short period. Like other process models, the RAD approach maps into the generic framework activities. Communication works to understand the business problem and the information characteristics that the software must accommodate. Planning is essential because multiple software teams work in parallel on different system functions. Modeling encompasses three major phases, business modeling, data modeling and process modeling and establishes design representations that serve as the basis for RAD’s construction activity. Construction emphasizes the use of pre-existing software components and the application of automatic code generation. Finally, deployment establishes a basis for subsequent iterations, if required. Obviously, the time constraints imposed on a RAD project demand “scalable scope”. If a business application can be modularized in a way that enables major function to be completed in less than three months, it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole. Like all process models, the RAD approach has drawbacks which are: • For large, but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. • If developers and customers are not committed to the rapid-fire activities necessary to complete the system in a much abbreviated time frame, the RAD project will fail. • If a system cannot be properly modularized, building the components necessary for RAD will be problematic. • If high performance is an issue, and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work. • RAD may not be appropriate when technical risks are high.

1.4 EVOLUTIONARY PROCESS MODELS.

 Software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight-line path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves over time. Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. http://wikistudent.ws/Unisa

1.4.1 PROTOTYPING.

Often, a customer defines a set of general objectives for software, but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach. Although prototyping can be used as a standalone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models. Regardless of the manner in which it is applied, the prototyping paradigm assists the software engineer and the customer to better understand what is to be built when requirements are fuzzy. The prototyping paradigm begins with communication. The software engineer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly and modeling (in the form of a quick design) occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer or end-user. The quick design leads to the construction of a prototype. The prototype is deployed and then evaluated by the customer or user. Feedback is used to refine requirements for the software. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done. Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is built, the developer attempts to make use of existing program fragments or applies tools that enable working programs to be generated quickly. In most projects, the first system built is barely usable. It may be too slow, too big, awkward in use or all three. There is no alternative but to start again and build a redesigned version in which these problems are solved. When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. The prototype can serve as the “first system”, the one we throw away. But this may be an idealized view. It is true that both customers and developers like the prototyping paradigm. Users get a feel for the actual system and developer get to build something immediately. Yet, prototyping can be problematic for the following reasons: • The customer sees what appears to be a working version of the software, unaware that the prototype is held together with strings, unaware that in the rush to get it working we haven’t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high-levels of quality can be maintained, the customer cries foul and demands that a few fixes be applied to make the prototype a working product. • The developer often makes implementation compromises in order to get a prototype working quickly. After a time, the developer may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system. Although problems can occur, prototyping can be an effective paradigm for stare engineering. The key is to define the rules of the game at the beginning; that is, the customer and developer must both agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part), and the actual software is engineered with an eye toward quality.

1.4.2 THE SPIRAL MODEL.

 http://wikistudent.ws/Unisa The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software. The spiral development model is a risk-driven process model generator that is used to guide multistakeholder concurrent engineering of software intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor pint milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions. Using the spiral mode, software is developed in a series of evolutionary releases. During early iterations, the release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a set of framework activities defined by the software engineering team. Each of the framework activities represents one segment of the spiral path. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk is considered as each revolution is made. Anchor point milestones are a combination of work products and conditions that are attained along the path of the spiral and are noted for each evolutionary pass. The first circuit around the path of the spiral might result in the development of a product specification; subsequent passes around the spiral might be sued to develop a prototype and then progressively more sophisticated version of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software. Unlike other process models that en when software is delivered, the spiral model can be adapted to apply throughout the life span of the computer software. The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risk at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but, more importantly, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risk at all stages of the project and, if properly applied, should reduce risk before they become problematic. But like other paradigms, the spiral model is not a solution and problems are: • It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. • It demands considerable risk assessment expertise and relies on the expertise for success. • If a major risk is not uncovered and managed, problems will occur.

 1.4.3 THE CONCURRENT DEVELOPMENT MODEL

. The concurrent development model, sometimes called concurrent engineering, can be represented schematically as a series of framework activities, software engineering actions and tasks, and their associated states. http://wikistudent.ws/Unisa The concurrent process model defines a series of events that will trigger transition from state to state for each of the software engineering activities, actions, or tasks. The concurrent process model is applicable to all types of software development and provides an accurate picture of the current stat of a project. Rather than confining software engineering activities, actions, and tasks to a sequence of events. Events generated at one point in the process network trigger transitions among the states.

1.4.4 A FINAL COMMENT ON EVOLUTIONARY PROCESSES. 

We have already noted that modern computer software is characterized by continual change, by very tight timelines and by an emphatic need for customer or user satisfaction. In many cases, time-tomarket is the most important management requirement. If a market window is missed, the software project it self may be meaningless. Evolutionary process models were conceived to address these issues, and yet, as a general class of process models, they too have concern-able weaknesses. These concerns are summarized as follows: • The first concerns is that prototyping and other more sophisticated evolutionary processes poses a problem to project planning because of the uncertain number of cycles required to construct the product. Most project management and estimation techniques are based on linear layouts of activities, so they do not fit completely. • Second, evolutionary software processes do not establish the maximum speed of the evolution. If the evolutions occur to fast, without a period of relaxation, it is certain that the process will fall into chaos. On the other hand, if the speed is too slow then productivity could be affected. • Third, software processes should be focused on flexibility and extensibility rather than on high quality. This assertion sounds scary. However, we should prioritize the speed of the development over zero defects. Extending the development in order to reach high quality could result in a late delivery of the product, when the opportunity niche has disappeared. This paradigm shift is imposed by the competition of the edge of chaos.

 CHAPTER 4 – AN AGILE VIEW OF PROCESS.

1.7 WHAT IS AGILITY?

 An agile team is an active team able to appropriately respond to changes. Change is what software development is very much about. Changes of all kinds that may have an impact on the product they build or the project that creates the product. Support for changes should be built-in everything we do in software. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project. The frequency of change is the primary driver for agility. Software engineers must be quick on their feet if they are to accommodate the rapid changes. But agility is more than an effective response to change. It also encourages team structures and attitudes that make communication more simplistic. It emphasizes rapid delivery of operational software and deemphasizes the importance of intermediate work products. It adopts the customer as part of the development team and works to eliminate the “us and them” attitude. It recognizes that planning in an uncertain world has its limits and that a project plan must be flexible. The twelve principles for those who want to achieve agility:

 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable          software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the      customer’s competitive advantage.
 3. Deliver working software frequently, from a couple of weeks to a couple of months, with                    preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.                                  http://wikistudent.ws/Unisa
5. Build projects around motivated individuals. Give them the environment and support they need,          and trust them to get the job done.
6. The most efficient and effective method of conveying information and within a development team        is face-to-face conversation.
 7. Working software is the primary measure of progress.
 8. Agile processes promote sustainable development. The sponsors, developers, and users should be        able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, the art of maximizing the amount of work not done is essential.
11. The best architectures, requirements, and designs emerge from self organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its       behavior accordingly.

Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them. Conduct planning in a way that understands the changeability of an agile development approach, eliminate all but the most essential work products and keep them lean, and emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment.

1.8 WHAT IS AN AGILE PROCESS.

 An agile software process is characterized in a manner that addresses three key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as a project proceeds.
 2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proves as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.
 3. Analysis, design, construction and testing are not as predictable, from a planning point of view, as we might like. An agile process must be adaptable. But continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback. An effective catalyst for customer feedback is an operational prototype or a portion of an operational system. Hence an incremental development strategy should be instituted. Software increments must be delivered in short time periods so that adaptation keeps pace with change. This iterative approach enables the customer to evaluate the software increment regularly, provide necessary feedback to the software team, and influence the process adaptations that are made to accommodate the feedback.

 1.9 AGILE PROCESS MODELS.

 1.9.1 EXTREME PROGRAMMING (XP).

 http://wikistudent.ws/Unisa Extreme programming uses and object-oriented approach as its preferred development paradigm. Extreme programming encompasses a set of rules and practices that occur within the context of four framework activities:

 1. Planning

 • Stories describe required features and functionality of software.

 • Each story is written by the customer and placed on an index card.

 • The customer assigns a value or priority to the story.

 • Members of the XP team assess each story and assign a cost, measured in development weeks.

 • If the story requires more than 3 weeks, the customer must split the story into smaller ones.

 • Customers and the XP team decide how to group stories into the next release or the next increment.  • Once a commitment is made for a release, the team orders the stories that will be developed in one      of three ways: o All stories will be implemented immediately. o The stories with highest value will    be implemented first. o The riskiest stories will be implemented first.

 • After the 1st release, the team computes project velocity, the number of customer stories                      implemented during the 1st release.

• Project velocity can then be used to: o Help estimate delivery dates & schedule for other releases. o    Determine whether an over-commitment has been made for all stories across the entire                        development project.

 • As work proceeds, the customer can add, change, split, or eliminate stories, and the team modifies       its plans accordingly.

 2. Design

 • A simple design is always preferred over a complex one.
• The design provides implementation guidance for a story.
• The design of extra functionality is discouraged.
• CRC cards identify and organize the object-oriented classes that are relevant.
• If a difficult design problem is encountered, create a prototype
 • Spike solution is the prototype that is implemented and evaluated.
• The only work products are CRC cards and spike solutions.
• Refactoring is improving the code design after it’s been written.
• Design occurs both before and after coding commences.

 3. Coding

 • Develop unit tests to exercise each story before coding.
 • When the code is complete, it can be unit tested immediately.
 • Pair programming is having two people work together at one computer to create code for a story,         for quality assurance.
 • As pair programmers complete their work, their code is integrated with the work of others, to               uncover errors early.
 • This continuous integration provides a smoke testing environment.

4. Testing

 • Tests should be automated to be executed easily and repeatedly.
 • Regression testing strategy whenever code is modified or refactored
.• As the individual unit tests are organized into a ‘universal testing suite’, integration and validation      testing of the system can occur on a daily basis.
 • This provides the team with a continual indication of progress.
 • Acceptance tests or customer tests are ones specified by customers and focus on overall features        that are visible. http://wikistudent.ws/Unisa

1.9.2 ADAPTIVE SOFTWARE DEVELOPMENT (ASD).

Adaptive software development has been proposed as a technique for building complex software and systems. The philosophical underpinnings of ASD focus on human collaboration and team selforganization.

 1. Speculation

  • The project is initiated and adaptive cycle planning is conducted
. • Adaptive cycle planning uses the customer’s mission statement, project constraints, and basic               requirements to define the set of release cycles that will be required.

2. Collaboration

 • Motivated people work together in a way that multiplies their talent and creative output beyond their absolute numbers.
 • People working together must trust one another to : o Criticize without animosity. o Assist without resentment. o Work as hard or harder as they do. o Have the skill set to contribute to the work at hand. o Communicate problems in ways that lead to effective action.

3. Learning

• ASD teams learn in 3 ways: o Focus groups where the customer or users provide feedback on software increments. o Formal technical reviews where ASD team members review the software components developed. o Postmortems where the team becomes introspective, addressing its own performance.

 1.9.3 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM). 

The dynamic systems development method is an agile software development approach that “provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment. The DSDM life cycle defines three different iterative cycles, preceded by two additional life cycle activities:

1. Feasibility study.

 • Establishes the basic business requirements and constraints.
 • Assesses whether the application is a viable candidate for DSDM. 2. Business study.
 • Establishes the functional and information requirements.
 • Defines the basic application architecture and identifies the maintainability requirements for the application.

 3. Functional model iteration.

 • Produces a set of incremental prototypes for demonstration.
 • All DSDM prototypes are intended to evolve into deliverables.
• Additional requirements are gathered by eliciting feedback from users as they exercise the prototype. http://wikistudent.ws/Unisa

 4. Design and build iteration.

• Revisits prototypes built during the functional model iteration to ensure that each will provide operational business value
. • Functional model iteration and Design and build iteration can occur concurrently.
 5. Implementation.
 • The latest software increment is placed into operation.
• Note that the increment may not be 100% complete, and changes may be requested as the increment is put into place
. • DSDM work continues by returning to the function model iteration.

 1.9.4 SCRUM.

   Scrum is an agile process model which principles are consistent with the agile manifesto.
 
• Small working teams are organized to maximize communication and knowledge, and minimize  overhead, and maximize sharing of unspoken, informal knowledge.
• The process must be adaptable to both technical and business changes.
• Frequent software increments
 • Work and people are partitioned.
• Constant testing and documentation.
• A product is declared ‘done’ whenever required.
• Scrum principles are used to guide development activities within a process that incorporates the following framework activities, requirements, analysis, design, evolution and delivery
.• Software process patterns define some development activities: o Backlog is a prioritized list of project requirements or features. Items can be added to the backlog at any time. o Sprints are work units that are required to achieve a requirement defined in the backlog that must fit into a time-box.

During the sprint, the backlog items it uses are frozen. o Scrum meetings are short daily meetings where these key questions are asked:

1. What did you do since the last team meeting?
2. What obstacles are you encountering
3. What do you plan to accomplish by the next meeting?

A ‘scrum master’ assesses the responses from each person. The meetings help the team uncover potential problems early. These daily meetings lead to ‘knowledge socialization’. o Demos are an increment delivered to the customer so that functionality can be demonstrated and evaluated. The demo may not contain all planned functionality, but only the functions delivered within the established time-box.

 1.9.5 CRYSTAL.

Crystal is an approach that puts a premium on maneuverability. Its primary goal is delivering useful, working software. The secondary goal is setting up for the next ‘game’. To achieve maneuverability, there is a set of methodologies to choose from, which all have core elements in common. Reflection workshops are conducted before, during, and after an increment is delivered. Crystal is called a ‘family of agile methods’ because the Crystal approach emphasizes collaboration and communication among people who have varying degrees of interest in the software project. The method is also tolerant of varying team cultures and can accommodate both informal and formal approaches. Crystal family is actually a set of sample agile processes that have been proved effective for different types of projects. The intent is to allow agile teams to select the member of the Crystal family that is most appropriate for their project.

1.9.6 FEATURE DRIVEN DEVELOPMENT (FDD).

 • A ‘feature’ is a client-valued function that can be implemented in two weeks or less
• Benefits of the emphasis on the definition of ‘features’: http://wikistudent.ws/Unisa o Because features are small, users can describe them more easily and better review them, and their design and code are easier to inspect effectively. o Features can be organized into a hierarchy. o The team develops operational features every two weeks. o Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an arbitrarily adopted software engineering task set.

• Five framework activities or processes:

1. Develop an overall model.
2. Build a features list.
3. Plan by feature.
4. Design by feature.
5. Build by feature.

• FDD provides greater emphasis on project management guidelines and techniques than many other agile methods.

 • To determine if software increments are properly scheduled, FDD defines 6 milestones:

1. Design walkthrough.
2. Design.
3. Design inspection.
4. Code.
5. Code inspection.
6. Promote to build

. 1.9.7 AGILE MODELING (AM).

• With large systems, scope and complexity must be modeled so that: o All can better understand what needs to be accomplished. o The problem can be partitioned effectively among the people. o Quality can be assessed at every step during engineering.

• AM is a methodology for modeling and documentation of software in a light-weight manner. AM provides guidance to practitioners during analysis and design. An agile team must have the courage to make decisions and humility to recognize that they don’t have all the answers.

 • Principles that make AM unique: o Model with a purpose. Have a specific goal before creating the model. o Use multiple models. Each model should present a different aspect of the system. o Travel light. Keep only the models that will provide long-term value. o Content is more important than representation. Modeling should impart information to its intended audience. o Know the models and the tools you use to create them. Understand the strengths and weaknesses of each model and tool. o Adapt locally. Adapt the modeling approach to the needs of the agile team. o

 CHAPTER 5 – SOFTWARE ENGINEERING PRACTICE.

 1.10 SOFTWARE ENGINEERING PRACTICE. People who create computer software practice the art or craft or discipline that is software engineering. In a generic sense, practice is a collection of concepts, principles, methods, and tools that a software engineer call upon a daily basis. Practice allows managers to manage software projects and software engineers to build computer programs. Practice populates a software process model with the necessary technical and management how-to’s to get the job done. Practice transforms a haphazard unfocused approach into something that is more organized, more effective and more likely to achieve success. Generic framework activities, communication, planning, modeling, construction, and deployment, and umbrella activities establish a skeleton architecture for software engineering work. All of the software process models can be mapped into this skeleton architecture. http://wikistudent.ws/Unisa

 1.10.1 THE ESSENCE OF PRACTICE. The essence of problem solving, and consequently, the essence of software engineering practice are:
 1. Understand the problem (Is communication and analysis).
 2. Plan a solution (Is modeling and software design).
3. Carry out the plan (Is code generation)
. 4. Examine the result for accuracy (Is testing and quality assurance)

. 1.10.2 CORE PRINCIPLES. The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought.” The seven core principles that focus on software engineering practice as a whole are:
 1. The reason it all exists. Software exists for one reason, to provide value to its users.
 2. KISS or Keep it simple, Stupid! All design should be as simple as possible, but no simpler.
3. Maintain the vision. A clear vision is essential to the success of a software project.
 4. What you produce others will consume. Always specify, design and implement knowing someone else will have to understand what you are doing
. 5. Be open to the future. Never design yourself into a corner.
6. Plan ahead for reuse. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the system into which they are incorporated.
7. Think! Placing clear, complete thought before action almost always produces better results.

1.11 COMMUNICATION PRACTICES. Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication (also called requirements elicitation) activity. The principles for communication practices are:
 1. Listen. Try to focus on the speaker’s words, rather than formulating your response to those words. As for clarification if something is unclear, but avoid constant interruptions never become contentious in your words or actions as a person is talking.
 2. Prepare before you communicate. Spend the time to understand the problem before you meet with others. If necessary, do some research to understand the business domain jargon. If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.
 3. Someone should facilitate the activity. Every communication meeting should have a leader or facilitator to keep the conversation moving in a productive direction, to mediate any conflict that does occur and to ensure that other principles are followed.
4. Face-to-face communication is best. But it is usually works better when some other representation of the relevant information is present.
5. Take notes and document decisions. Things have a way of falling into the cracks. Someone participating in the communication should serve as a recorder and write down all important points and decisions. http://wikistudent.ws/Unisa
6. Strive for collaboration. Collaboration and consensus occur when the collective knowledge of members of the team is combined to describe product or system functions or features. Each small collaboration serves to build trust among team members and creates a common goal for the team.
 7. Stay focused, modularize your discussion. The more people involved in any communication, the more likely that discussion will bounce from one topic to the next. The facilitator should keep the conversation modular, leaving one topic only after it has been resolved
. 8. If something is unclear, draw a picture. Verbal communication goes only so far. A sketch or drawing can often provide clarity when fords fail to do the job.
 9. Once you agree to something, move on; If you can’t agree to something, move on; If a feature or function is unclear and cannot be clarified at the moment, move on. Communication like any software engineering activity, takes time. Rather than iterating endlessly, the people who participate should recognize that many topics require discussion and that “moving on” is sometimes the best way to achieve communication agility.
 10. Negotiation is not a contest or a game. It works best when both parties win. There are many instances in which the software engineer and the customer must negotiate functions and features, priorities, and delivery dates. If the team has collaborated well, the parties have a common goal. Therefore, negotiations will demand compromise from all parties
. 1.12 PLANNING PRACTICES. The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels towards its strategic goal and tactical objectives. The principles for planning practices are: 1. Understand the scope of the project. It’s impossible to use a road map if you don’t know where you’re going. Scope provides the software team with a destination. 2. Involve the customer in the planning activity. The customer defines priorities and establishes project constraints. To accommodate these realities, software engineers must often negotiate order of delivery, timelines, and other project related issues. 3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes. In addition, iterative, incremental process models dictate replanning based on feedback received from the users. 4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of work to be done. If information is vague or unreliable, estimates will be equally unreliable.
 5. Consider risk as you define the plan. If the team has defined risks that have high impact and high probability, contingency planning is necessary. In addition, the project plan should be adjusted to accommodate the likelihood that one or more of these risks will occur.
6. Be realistic. People don’t work 100 percent of every day. Noise always enters into any human communication. Omissions and ambiguity are facts of life. Change will occur. Even the best software engineers make mistakes. These and other realities should be considered as project plan is established. http://wikistudent.ws/Unisa
 7. Adjust granularity as you define the plan. Granularity refers to the level of detail that is introduced as a project plan is developed. A “fine granularity” plan provides significant work task detail that is planned over relatively short time increments. A “coarse granularity” plan provides broader work tasks that are planned over longer time periods. In general, granularity moves from fine to coarse as the project timeline moves away from the current date. Over the next few weeks or months, the project can be planned in significant detail. Activities that won’t occur for many months do not require fine granularity.
 8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. If formal technical reviews are to be conducted, they should be scheduled. If pair programming is to be used during construction, it should be explicitly defined within the plan.
9. Describe how you intend to accommodate change. Even the best planning can be delayed by uncontrolled change. The software team should identify how changes are to be accommodated as software engineering work proceeds.
10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. Therefore, it makes sense to track progress on a daily basis, looking for problem areas and situations in which scheduled work does not conform to actual work conducted. When slippage is encountered, the plan is adjusted accordingly