Feature-driven development
Feature-driven development is an iterative and incremental software development process. It is a Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole; these practices are driven from a client-valued functionality perspective. Its main purpose is to deliver tangible, working software in a timely manner. FDD was devised by Jeff De Luca to meet the specific needs of a 15-month, 50-person software development project at a large Singapore bank in 1997; this resulted in a set of five processes that covered the development of an overall model and the listing, planning and building of features. The first process is influenced by Peter Coad's approach to object modelling; the second process incorporates Coad's ideas of using a feature list to manage functional requirements and development tasks. The other processes are a result of Jeff De Luca's experience. There have been several implementations of FDD since its successful use on the Singapore project.
The description of FDD was first introduced to the world in Chapter 6 of the book Java modelling in Color with UML by Peter Coad, Eric Lefebvre, Jeff De Luca in 1999. In Stephen Palmer and Mac Felsing's book A Practical Guide to Feature-Driven Development, a more general description of FDD was given decoupled from Java modelling. FDD is a model-driven short-iteration process. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined; this section gives a high level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established; the final three activities are iterated for each feature. The FDD project starts with a high-level walkthrough of the scope of its context. Next, detailed domain models are created for each modelling area by small groups and presented for peer review.
One or more of the proposed models are selected to become the model for each domain area. Domain area models are progressively merged into an overall model. Knowledge gathered during the initial modeling is used to identify a list of features by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the basis for a categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form "<action> <result> <object>", for example:'Calculate the total of a sale' or'Validate the password of a user'. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces. After the feature list is completed, the next step is to produce the development plan and assign ownership of features as classes to programmers. A design package is produced for each feature. A chief programmer selects a small group of features. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model.
Next, the class and method prologues are written and a design inspection is held. After a successful design inspection for each activity to produce a feature is planned, the class owners develop code for their classes. After unit testing and successful code inspection, the completed feature is promoted to the main build. Since features are small, completing a feature is a small task. For accurate state reporting and keeping track of the software development project, it is important to mark the progress made on each feature. FDD therefore defines six milestones per feature; the first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To track progress, a percentage complete is assigned to each milestone. In the table below the milestones and their completion percentage are shown. At the point that coding begins, a feature is 44% complete. Feature-driven development is built on a core set of software engineering best practices aimed at a client-valued feature perspective.
Domain Object modelling. Domain Object modelling consists of explaining the domain of the problem to be solved; the resulting domain object. Developing by Feature. Any function, too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature; this makes it easier to extend or modify the system. Individual Class Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner; the owner is responsible for the consistency and conceptual integrity of the class. Feature Teams. A feature team is a small, dynamically formed team. Multiple minds are always applied to each design decision, multiple design options are evaluated before one is chosen. Inspections. Inspections are carried out to ensure good quality design and code by detection of defects. Configuration Management. Configuration management helps with identifying the source code for all features that have been completed to date and maintaining a history of changes to classes as feature teams enhance them.
Regular Builds. Regular builds ensure there is always an up-to-date system that can be
Scrum (software development)
Scrum is an agile framework for managing knowledge work, with an emphasis on software development, although it has wide application in other fields and is starting to be explored by traditional project teams more generally. It is designed for teams of three to nine members, who break their work into actions that can be completed within timeboxed iterations, called sprints, no longer than one month and most two weeks track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums. Approaches to coordinating the work of multiple scrum teams in larger organizations include large-scale scrum, scaled agile framework, scrum of scrums, Scrum@Scale, the Nexus, among others. Scrum is a lightweight and incremental framework for managing product development, it defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.
A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. As such, Scrum adopts an evidence-based empirical approach—accepting that the problem cannot be understood or defined up front, instead focusing on how to maximize the team's ability to deliver to respond to emerging requirements, to adapt to evolving technologies and changes in market conditions. Scrum is seen written in all-capitals, as SCRUM; the word is not an acronym, so this is not correct. While the trademark on the term Scrum itself has been allowed to lapse, it is deemed as owned by the wider community rather than an individual, so the leading capital for Scrum is retained in this article. Many of the terms used in Scrum are written with leading capitals. However, to maintain an encyclopedic tone, this article uses normal sentence case for these terms — unless they are recognized marks.
Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, "The New New Product Development Game". Takeuchi and Nonaka argued in The Knowledge Creating Company that it is a form of "organizational knowledge creation good at bringing about innovation continuously and spirally"; the authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive and printer industries. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth". In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods. In 1995, Sutherland and Schwaber jointly presented a paper describing the scrum framework at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Languages & Applications'95 in Austin, Texas.
Over the following years and Sutherland collaborated to combine this material—with their experience and evolving good practice—to develop what became known as Scrum. In 2001, Schwaber worked with Mike Beedle to describe the method in the book, Agile Software Development with Scrum. Scrum's approach to planning and managing product development involves bringing decision-making authority to the level of operation properties and certainties. In 2002, Schwaber with others founded the Scrum Alliance and set up the Certified Scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org which oversees the parallel Professional Scrum accreditation series. Since 2009, a public document called The Scrum Guide has defined Scrum, it has been revised 5 times, with the current version being November 2017. In 2018, Schwaber and the Scrum.org community, along with leaders of the Kanban community, published The Kanban Guide for Scrum Teams. There are three roles in the scrum framework.
These are ideally co-located to ensure optimal communication among team members. Together these three roles form the scrum team. While many organizations have other roles involved with defining and delivering the product, Scrum defines only these three; the product owner represents the product's stakeholders and the voice of the customer, is responsible for the product backlog and accountable for maximizing the value that the team delivers. The product owner defines the product in customer-centric terms, adds them to the product backlog, prioritizes them based on importance and dependencies. A scrum team should have only one product owner; this role should not be combined with that of the scrum master. The product owner should focus on the business
Requirements analysis
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the conflicting requirements of the various stakeholders, documenting and managing software or system requirements. Requirements analysis is critical to the failure of a systems or software project; the requirements should be documented, measurable, traceable, related to identified business needs or opportunities, defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes three types of activities: Eliciting requirements:, business process documentation, stakeholder interviews; this is sometimes called requirements gathering or requirements discovery. Analyzing requirements: determining whether the stated requirements are clear, complete and unambiguous, resolving any apparent conflicts. Recording requirements: Requirements may be documented in various forms including a summary list and may include natural-language documents, use cases, user stories, process specifications and a variety of models including data models.
Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. Large systems may confront analysts with thousands of system requirements. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer; these may include the development of scenarios, the identification of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups and creating requirements lists. Prototyping may be used to develop an example system. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Requirements quality can be improved through these and other methods Visualization.
Using tools that promote better understanding of the desired end-product such as visualization and simulation. Consistent use of templates. Producing a consistent set of models and templates to document the requirements. Documenting dependencies. Documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations. See Stakeholder analysis for a discussion of people or organizations that have a valid interest in the system, they may be affected by it either indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders, it is recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: anyone who operates the system anyone who benefits from the system anyone involved in purchasing or procuring the system. In a mass-market product organization, product management and sometimes sales act as surrogate consumers to guide development of the product. Organizations which regulate aspects of the system people or organizations opposed to the system organizations responsible for systems which interface with the system under design.
Those organizations who integrate horizontally with the organization for whom the analyst is designing the system. Requirements have cross-functional implications that are unknown to individual stakeholders and missed or incompletely defined during stakeholder interviews; these cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements which meet the session objective. JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.
One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages long. An appropriate metaphor would be an long shopping list; such lists are much out of favour in modern analysis. Provides a checklist of requirements. Provide a contract between the project sponsor and developers. For a large system can provide a high level description from which lower-level requirements can be derived; such lists can run to hundreds of pages. They are not intended to serve as a reader-friendly description of the desired application; such requirements lists abstract all the requirements and so there is little context. The Business Analyst may include context for requirements in accompanying design documentation. Thi
Software development process
In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, project management. It is known as a software development life cycle; the methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application. Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping and incremental development, spiral development, rapid application development, extreme programming; some people consider a life-cycle "model" a more general term for a category of methodologies and a software development "process" a more specific term to refer to a specific process chosen by a specific organization. For example, there are many specific software development processes that fit the spiral life-cycle model; the field is considered a subset of the systems development life cycle.
The software development methodology framework didn't emerge until the 1960s. According to Elliott the systems development life cycle can be considered to be the oldest formalized methodology framework for building information systems; the main idea of the SDLC has been "to pursue the development of information systems in a deliberate and methodical way, requiring each stage of the life cycle––from inception of the idea to delivery of the final system––to be carried out rigidly and sequentially" within the context of the framework being applied. The main target of this methodology framework in the 1960s was "to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines". Methodologies and frameworks range from specific proscriptive steps that can be used directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a custom set of steps tailored to the needs of a specific project or group.
In some cases a "sponsor" or "maintenance" organization distributes an official set of documents that describe the process. Specific examples include: 1970sStructured programming since 1969 Cap Gemini SDM from PANDATA, the first English translation was published in 1974. SDM stands for System Development Methodology1980sStructured systems analysis and design method from 1980 onwards Information Requirement Analysis/Soft systems methodology1990sObject-oriented programming developed in the early 1960s, became a dominant programming approach during the mid-1990s Rapid application development, since 1991 Dynamic systems development method, since 1994 Scrum, since 1995 Team software process, since 1998 Rational Unified Process, maintained by IBM since 1998 Extreme programming, since 19992000sAgile Unified Process maintained since 2005 by Scott Ambler Disciplined agile delivery Supersedes AUP2010s Scaled Agile Framework Large-Scale Scrum DevOpsIt is notable that since DSDM in 1994, all of the methodologies on the above list except RUP have been agile methodologies - yet many organisations governments, still use pre-agile processes.
Software process and software quality are interrelated. Among these another software development process has been established in open source; the adoption of these best practices known and established processes within the confines of a company is called inner source. Several software development approaches have been used since the origin of information technology, in two main categories. An approach or a combination of approaches is chosen by management or a development team. "Traditional" methodologies such as waterfall that have distinct phases are sometimes known as software development life cycle methodologies, though this term could be used more to refer to any methodology. A "life cycle" approach with distinct phases is in contrast to Agile approaches which define a process of iteration, but where design and deployment of different pieces can occur simultaneously. Continuous integration is the practice of merging all developer working copies to a shared mainline several times a day. Grady Booch first named and proposed CI in his 1991 method, although he did not advocate integrating several times a day.
Extreme programming adopted the concept of CI and did advocate integrating more than once per day – as many as tens of times per day. Software prototyping is about creating prototypes, i.e. incomplete versions of the software program being developed. The basic principles are: Prototyping is not a standalone, complete development methodology, but rather an approach to try out particular features in the context of a full methodology. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process; the client is involved throughout the development process, which increases the likelihood of client acceptance of the final implementation. While some prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problems, but this is true for all software methodologies.
Various methods are acceptable f
Domain-driven design
Domain-driven design is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following: placing the project's primary focus on the core domain and domain logic; the term was coined by Eric Evans in his book of the same title. Concepts of the model include: Context The setting in which a word or statement appears that determines its meaning; the subject area to which the user applies a program is the domain of the software. Ideally, it would be preferable to have a unified model. While this is a noble goal, in reality it fragments into multiple models, it is useful to recognize this fact of work with it. Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models. Multiple models are in play on any large project, yet when code based on distinct models is combined, software becomes buggy and difficult to understand. Communication among team members becomes confusing.
It is unclear in what context a model should not be applied. Therefore: Explicitly define the context within. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, physical manifestations such as code bases and database schemas. Keep the model consistent within these bounds, but don’t be distracted or confused by issues outside; when a number of people are working in the same bounded context, there is a strong tendency for the model to fragment. The bigger the team, the bigger the problem, but as few as three or four people can encounter serious problems, yet breaking down the system into ever-smaller contexts loses a valuable level of integration and coherency. Therefore: Institute a process of merging all code and other implementation artifacts with automated tests to flag fragmentation quickly. Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads. An individual bounded context leaves some problems in the absence of a global view.
The context of other models may still be vague and in flux. People on other teams won’t be aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections; when connections must be made between different contexts, they tend to bleed into each other. Therefore: Identify define its bounded context; this includes the implicit models of non-object-oriented subsystems. Name each bounded context, make the names part of the ubiquitous language. Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain. In the book Domain-Driven Design, a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements, that works well for the business users or sponsors and for the software developers; the book is focused on describing the domain layer as one of the common layers in an object-oriented system with a multilayered architecture.
In DDD, there are artifacts to express and retrieve domain models: Entity An object, not defined by its attributes, but rather by a thread of continuity and its identity. Example: Most airlines distinguish each seat uniquely on every flight; each seat is an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat. In this context, a seat is a value object. Value object An object that contains has no conceptual identity, they should be treated as immutable. Example: When people exchange business cards, they do not distinguish between each unique card. In this context, business cards are value objects. Aggregate A collection of objects that are bound together by a root entity, otherwise known as an aggregate root; the aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members. Example: When you drive a car, you do not have to worry about moving the wheels forward, making the engine combust with spark and fuel, etc..
In this context, the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems. Domain Event A domain object. A domain event is an event. Service When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. See Service. Repository Methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be interchanged. Factory Methods for creating domain objects should delegate to a specialized Factory object such that alte
Stand-up meeting
A stand-up meeting is a meeting in which attendees participate while standing. The discomfort of standing for long periods is intended to keep the meetings short. By tradition, the Privy Council of the United Kingdom meets standing; some software development methodologies envision daily team-meetings to make commitments to team members. The daily commitments allow participants to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues; the stand-up has particular value in Agile software development processes, such as Scrum or Kanban, but can be utilized in context of any software-development methodology. The meetings are timeboxed to between 5 and 15 minutes, take place with participants standing up to remind people to keep the meeting short and to-the-point; the stand-up meeting is sometimes referred to as the "stand-up", "morning rollcall" or "daily scrum". The meeting should place every working day. All team members are encouraged to attend, but the meetings are not postponed if some of the team members are not present.
One of the crucial features is that the meeting is a communication opportunity among team members and not a status update to management or stakeholders. Although it is sometimes referred to as a type of status meeting, the structure of the meeting is meant to promote follow-up conversation, as well as to identify issues before they become too problematic; the practice promotes closer working relationships in its frequency, need for follow-up conversations and short structure, which in turn result in a higher rate of knowledge transfer – a much more active intention than the typical status meeting. Team members take turns speaking, sometimes passing along a token to indicate the current person allowed to speak; each member talks about progress since the last stand-up, the anticipated work until the next stand-up and any impediments, taking the opportunity to ask for help or collaborate. Team members may sometimes ask for short clarifications and make brief statements, such as "Let's talk about this more after the meeting", but the stand-up does not consist of full-fledged discussions.
Scrum-style stand-ups convene daily to re-plan in-progress development. Though it may not be practical to limit all discussion to these three questions, the objective is to create a new sprint plan within the time box, while deferring discussions about impediments until after the event is complete. Team members address three questions as input to this planning: What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal? Whereas Kanban-style daily stand-ups focus more on: What obstacles are impeding my progress? What has progressed? Lean software development Five Ws A pocket guide for effective stand-up meetings Patterns Of Daily Stand-up Meetings, Jason Yip Are your standups awesome? Article Opening Communication within a Scrum Team from Methods & Tools Straya, Viktoria. K.. "The daily stand-up meeting: A grounded theory study".
Journal of Systems and Software. 114: 101–124. Doi:10.1016/j.jss.2016.01.004. Retrieved 2016-03-01
Incremental build model
The incremental build model is a method of software development where the product is designed and tested incrementally until the product is finished. It involves both development and maintenance; the product is defined. This model combines the elements of the waterfall model with the iterative philosophy of prototyping; the product is decomposed into a number of components, each of, designed and built separately. Each component is delivered to the client; this avoids a long development time. It avoids a large initial capital outlay and subsequent long waiting period; this model of development helps ease the traumatic effect of introducing a new system all at once. The incremental model applies the waterfall model incrementally; the series of releases is referred to as “increments”, with each increment providing more functionality to the customers. After the first increment, a core product is delivered, which can be used by the customer. Based on customer feedback, a plan is developed for the next increments, modifications are made accordingly.
This process continues, with increments being delivered. The incremental philosophy is used in the agile process model; the Incremental model can be applied to DevOps. In DevOps it centers around the idea of minimizing risk and cost of a DevOps adoption whilst building the necessary in-house skillset and momentum. Characteristics of Incremental Model System is broken down into many mini development projects. Partial systems are built to produce the final system. First tackled highest priority requirements; the requirement of a portion is frozen. Advantages After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be identified because few changes are made within any single iteration, it is easier to test and debug than other methods of software development because smaller changes are made during each iteration. This allows for more rigorous testing of each element within the overall product. Customer can review the product for any needed or useful changes.
Initial product delivery is costs less. Disadvantages Resulting cost may exceed the cost of the organization; as additional functionality is added to the product, problems may arise related to system architecture which were not evident in earlier prototypes These tasks are common to all the models Communication: helps to understand the objective. Planning: required as many people work on the same project but different function at same time. Modeling: involves business modeling, data modeling, process modeling. Construction: this involves the reuse software components and automatic code. Deployment: integration of all the increments. Iterative and incremental development Rapid application development Incremental approach Methodology::Development Models Incremental lifecycle What is Incremental model - advantages and when to use it Incremental Model in Software Engineering
