A low-code development platform (LCDP) provides a development environment used to create application software through a graphical user interface instead of traditional hand-coded computer programming. A low-coded platform may produce entirely operational applications, or require additional coding for specific situations. Low-code development platforms reduce the amount of traditional hand coding, enabling accelerated delivery of business applications
Scrum is an agile framework for managing work with an emphasis on software development.
It is designed for development teams of between three to nine members who break their work into actions that can be completed within timeboxed iterations, called sprints (30 days or less, most commonly two weeks) and track progress and re-plan in 15-minute stand-up meetings, called daily scrums
Scrum is an iterative and incremental agile software development framework for managing product development.
https://en.wikipedia.org/wiki/Scrum_(software_development)
Product Backlog: an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
Sprint Planning: time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.
Sprint Review: time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.
Daily Scrum: daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.
Sprint Retrospective: time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.
Sprint: time-boxed event of 30 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
Scrum Master: the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum
Product Owner: the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).
Burn-down Chart: a chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.
Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team
Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole - form a product.
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
Scrum Teams are self-organizing and cross-functional.
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team
https://www.scrum.org/resources/what-is-scrum
Professional Scrum Developer™ (PSD) is a 3-day course where students make up an entire Scrum Team where they concurrently do requirements engineering, design, development, testing, integration and deployment within a single iteration.
Course Topics
Using Scrum
Working within a Scrum Team
Definition of Done
Development Practices
Test Driven Development
Pair Programming
Code Review
Using ALM tools with Scrum
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum
All events are time-boxed.
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.
Product Backlog
Sprint Backlog
Increment
https://www.scrum.org/resources/what-is-scrum
iceScrum is a web application for using Scrum while keeping the spirit of a collaborative workspace. It also offers virtual boards with post-its for sprint backlog, product backlog and others.
https://github.com/icescrum/iceScrum
Planning Poker® is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs
To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.
The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.
How does poker planning work with a distributed team?
Simple: go to PlanningPoker.com. A product owner, ScrumMaster or agile coach can log in and preload a set of items to be estimated. A private URL can then be shared with estimators who log in and join a conference call or Skype session. Agile estimating and planning then proceeds as it would in person.
Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.
https://www.leadingagile.com/2016/09/whats-a-spike-who-should-enter-it-how-to-word-it/
The first sprint
Now that the prep work?whether in the form of a DAD Inception phase, a "sprint zero," or a "project before the project"?has been completed, it's time for that first sprint.
Your first agile sprint is a baseline and getting everything "right" isn't as important as getting the team to understand the general spirit of agile. The iterations are short so the team should be able to quickly gather feedback and continue to adapt and improve over time.
Weighted Shortest Job First is a technique for a) assigning a weight, or value, to each job, and then b) dividing that by the length of the job, in order to c) determine a relative ranking
Weighted Shortest Job First (WSJF) is a technique for backlog prioritization recommended by Dean Leffingwell. The calculation involves measures for User Value, Time Value, Risk Reduction / Opportunity Enablement Value, and Job Size::
WSJF = (User Value + Time Value + RROE Value) / Job Size
https://www.scrum.org/forum/scrum-forum/5509/weighted-shortest-job-first
Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
https://www.scruminc.com/velocity/
Large-Scale Scrum (LeSS)
a lightweight (agile) framework for scaling Scrum to more than one team.
LeSS consists of the LeSS Principles, the Framework, the Guides and a set of experiments. The LeSS framework is divided into two frameworks: basic LeSS for 2-8 teams and LeSS Huge for 8+ teams.
https://www.agilealliance.org/resources/sessions/introduction-to-large-scale-scrum-less/
Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules.
LeSS provides two different large-scale Scrum frameworks.
The two frameworks – which are basically single-team Scrum scaled up – are:
LeSS: Up to eight teams (of eight people each).
LeSS Huge: Up to a few thousand people on one product.
In LeSS, you will find:
a single Product Backlog (because it’s for a product, not a team),
one Definition of Done for all teams,
one Potentially Shippable Product Increment at the end of each Sprint,
one Product Owner,
many complete, cross-functional teams (with no single-specialist teams),
one Sprint
https://less.works/less/framework/index.html
Scaled Agile Framework® (SAFe®) empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale. SAFe is designed to help businesses continuously and more efficiently deliver value on a regular and predictable schedule. It provides a knowledge base of proven, integrated principles and practices to support enterprise agility.
https://www.scaledagileframework.com/
The Scaled Agile Framework (abbreviated as SAFe), is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices.
https://en.wikipedia.org/wiki/Scaled_agile_framework
In traditional scaling frameworks, specific practices (e.g. daily standups) are how the framework is executed, whereas the Spotify model focuses on how businesses can structure an organization to enable agility.
Key elements of the Spotify model
Squads
Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6-12 individuals) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. Squads determine which agile methodology/framework will be used.
Tribes
When multiple Squads coordinate within each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40 - 150 people in order to maintain alignment.Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.
Chapter
Even though Squads are autonomous, it’s important that specialists (e.g. Javascript Developer, DBAs) align on best practices. Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology lead, who may also be the manager for the team members in that Chapte
Guild
Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and they are completely voluntary. Whereas Chapters belong to a Tribe, Guilds can cross different Tribes. There is no formal leader of a Guild. Rather, someone raises their hand to be the Guild Coordinator and help bring people together.
Trio
The Trio (aka TPD Trio) is a combination of a Tribe Lead, product lead, and design lead. Each Tribe has a Trio in place to ensure there is continuous alignment between these three perspectives when working on features areas.
Alliance
As organizations scale, sometimes multiple Tribes need to closely work together to accomplish a goal. Alliances are a combination of Tribe Trios (typically three or more) that work together to help their Tribes collaborate on a goal that is bigger than any one Tribe.
Squads may have ceremonies like sprint planning and retrospectives, but the focus of the Spotify model is on how teams organize around work. It’s up to Squads to figure out the best way to get the job done.
The benefits of the Spotify model
Less formal process and ceremony
More self-management and autonomy
The Spotify model focuses on decentralizing decision making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.
The challenges of the Spotify model
Some organizations experienced more success than others, but it’s likely no organization experienced the same success as Spotify. The reason? Like any way of working, an organization's current culture and structure need to be taken into account. The model is simple, but the environment it's implemented in is complex.
To some, it may seem like a simple matrix organizational structure where people report to a functional area (Chapter), but work with a cross-functional team (Squad).
Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy.
If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized.
Spotify model best practices
Don’t copy the model
Seek to understand the structure, practices, and mindset behind Spotify’s approach. With that understanding, tweak the aspects of the model to fit your own environment. Your goal is not to be Spotify, but to leverage their model to improve how your organization works together.
Autonomy and trust is key
Allowing teams to pick their own development tools and modify another team's code are just some examples. Within your organization, determine if there are decisions that can be pushed to the teams instead of being mandated by parts of the organization that are disconnected from the day-to-day work.
Transparency with community
Establish your first Guild around the Spotify model adoption and encourage participation from everyone in the organization. Build trust by creating transparent, inclusive ways to gather feedback, and gain alignment on how your organization wants to work in the future.
Encourage mistakes
Spotify doesn’t leverage the original implementation of the Spotify model anymore; they evolved and adapted the model to fit their changing organization. Trios and Alliances are actually newer elements in Spotify as they were brought about to solve new problems the organization faced as it grew larger.
Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person
https://en.wikipedia.org/wiki/Dunbar%27s_number
Scaled Agile Framework (SAFe):
The current version is SAFe 5.1, which got revised in February 2021. It has four constructs — Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe. It would be best if you had either portfolio or full SAFe to achieve business agility through SAFe. The SAFe structure grows when you move from one level to another by adding new roles and responsibilities.
Large-Scale Scrum (LeSS):
It developed by taking Scrum and trying many different experiments to discover what works. In 2013, the experiments were solidified into the LeSS framework rules.
Opposite to SAFe, LeSS talks about descaling Structure and organizational complexity to enable simplicity at scale.
Spotify Model Framework:
Spotify model talks about Squad, tribe, chapter, and gild, where the squad is a cross-functional team designed based on the customer journey.
The tribe is a collection of squads, and the chapter is more like a community of practices. However, the definition of chapter and tribe has changed a lot lately, where it gives a feeling of a matrix organization. The Spotify model doesn’t have any rules or guidelines publicly available like SAFe and LeSS. It gives many organizations a quick win because of multiple factors, including renaming the existing team as a squad. In the Spotify model, teams usages LeSS, SAFe, Scrum, or Kanban at the squad or tribe level.
Nexus Framework
Nexus is similar to LeSS from outside minus nexus integration team. It is a framework build upon Scrum but keeps Scrum untouched. If multiple teams work on the same product and experience coordination chaos, then Nexus may be helpful. A Nexus is a group of approximately three to nine Scrum Teams who work together to deliver a single product; it connects people and things. A Nexus has a single Product Owner who manages a single Product Backlog from which the Scrum Teams work. Unlike LeSS, Nexus doesn’t come up with its principles and uses the Scrum framework’s principles.
Look at some simple parameters to decide:
Is it about product development or service delivery?
Scrum@Scale is Scrum scaled for the whole organisation
Spotify Engineering Culture may be a best fit for component teams
SAFe puts the purpose of Scrum under heavy pressure due to it’s top-down approach, additional layers and as a result additional roles, events and artifacts.
Spotify allows for a lot of autonomy for the teams to work according to Scrum. The focus on small decoupled systems however is a different perspective than Scrum’s perspective of optimizing the value of a product. Spotify can be your scaling approach of choice if you don’t have the concerns of systems vs product.
It is essential to note that SAFe® is intended to accommodate DevOps, a process frequently deemed for future-proof Agile organizations.
It is most desirable for large organizations to retain as much organizational and process structure as possible while reaping the advantages of a decentralized Agile method.
SAFe® is not as efficiently customizable as Scrum at Scale
Scrum@Scale
The Scrum@Scale structure is easily manageable but hard to master. It is made up of 2 cycles, the Scrum Master cycle and Product Owner cycle, and 12 components necessary to execute Scrum at scale.
SAFe® vs. Large-Scale Scrum (LeSS)
Scaled Agile Framework
Benefits of SAFe®
SAFe® separates business strategies into actions, then features, then stories of work at the team level, and maps the pathway.
Drawbacks of SAFe®
The implementation pathway is required to be tweaked to meet the requirements of your organization
Large Scale Scrum (LeSS)
A necessary characteristic of LeSS comprises redirecting team awareness over the entire organization.
Limitations of LeSS
Scaling only works for an organization which has an extensive Scrum foundation
LeSS is formed around Scrum and is not a straightforward extension of other methodologies.
A single Product Owner may attempt to control multiple teams
SAFe® vs Spotify
Spotify: a lightweight framework
Unlike SAFe®, the Spotify model is not considered an extensive toolbox. The Spotify model contributes a relatively lightweight framework that stresses the necessity to generate many interactions to limit the silo side formed by teams.
It would be essential to determine how every team must work in a standard way or have 100% freedom provided to the groups. Moreover, the Spotify model doesn’t deliver any solution to control the Portfolio like SAFe®.
SAFe® a heavy framework
Unlike the Spotify model, everything is already fixed, and only an expert can be expected to have the imagination to improve it.
Challenges of scaling agile principles and practices
The Scaled Agile Framework discusses the obstacles encountered when scaling agile beyond a single team.
This practice of practicing a routine until it became a refined habit now extends beyond martial arts and into business.
the Toyota Motor Corporation developed continuous improvement through practiced patterns.
This technique, called Improvement Kata
Improvement Kata is a method where team leaders and members continually practice a kata routine that develops and channels their abilities to problem-solve. Over time, the practices become second nature.
It seeks to do so with a four-part model:
Understand the direction or challenge
Grasp the current condition
Define the target destination
Move toward the target iteratively, which reveals obstacles to overcome
These techniques are particularly helpful when the route to a destination is unclear, as experimentation can help you better understand the problem and find unique solutions.
What are the benefits of Improvement Kata?
Teams aligned toward a single goal
Experimentation leads to results
Reduce waste significantly
What are some examples of Improvement Kata?
Say you want to build a new service based on an idea, but you’re not sure whether it will work. Rather than trying to get every layer perfectly worked out and incrementally expanding it until it’s feature-complete, try picking a target that delivers some value and brings you closer to the system you envisioned. You’ll probably have lots of unknowns, but you can learn a lot from challenges, and experiment with different ideas to find one that works. Once it does, reevaluate where you are, pick your next target, iterate, and reflect on your progress.
What are the differences between Improvement Kata and lean?
Kata and lean are different, yet compliment each other. Kata and Lean are different in many ways. Lean refers to processes to be implemented while kata refers to techniques to be practiced. Thus, kata became a mainstream business practice when Toyota adopted it into its lean production system. When combined into a unified approach, these concepts provide powerful results.
Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment
Agile
Agile refers to a set of values and principles put forth in the Agile Manifesto. The Manifesto was a reaction against heavyweight methodologies that were popular, yet crippling software projects from actually doing what they needed to do
http://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference
A Library is a reusable set of types/functions you can use from a wide variety of applications. The application code initiates communication with the library and invokes it.
A Framework consists of one or more libraries, but the difference is that Inversion of Control applies. The application registers with the framework (often by implementing one or more interfaces), and the framework calls into the application, which may call back into the framework. A framework often exists to address a particular general-purpose Domain (such as web applications, or workflows, etc.). Architecture consists of the guiding principles behind a given application. It is not strongly tied to a particular framework or library.
Frameworks is a collection of classes and tools that help you developing great softwares ... like .net framework or Qt. Architecture is entirely different : it refers to design pattern or how an application or a framework is organized. What are the modules that compose it and how they communicate together
Architecture is about style, abstract idea, flow, methodology, concept. Framework is something which implements the style, idea, concept etc..or makes it easier to implement it. example,
Architecture: Every component should have standard pluggable interfaces and it should be possible to connect any component to any other.
Framework: Then lego building blocks can be the framework.
Library: some readymade combinations of blocks that would work as the pillars.
Application: A building structure using the pillars and other building blocks(application).
Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern, and is used mostly for building user interfaces. http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
Model View ViewModel Model View ViewModel (MVVM) is an architectural pattern for software development. MVVM is a variation of Martin Fowler's Presentation Model design pattern. Model View ViewModel is also called model-view-binder, especially in implementations that don't involve the .NET platform
Components of the MVVM pattern Model Model refers either to a domain model, which represents the real state content (an object-oriented approach), or to the data access layer that represents that content (a data-centric approach) View As in the MVC and MVP patterns, the view is the user interface (UI). View model The view model is an abstraction of the view that exposes public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder. In the view model, this binder mediates communication between the view and the data binder.The view model has been described as a state of the data in the model. Binder Declarative data- and command-binding are implicit in the MVVM pattern. In the Microsoft solution stack, the binder is a markup language called XAML.[7] The binder frees the developer from being obliged to write boiler-plate logic to synchronise the view model and view. When implemented outside of the Microsoft stack the presence of a declarative databinding technology is a key enabler of the pattern http://en.wikipedia.org/wiki/Model_View_ViewModel
In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time
Single responsibility principle a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class) Open/closed principle “software entities … should be open for extension, but closed for modification.” Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Interface segregation principle “many client-specific interfaces are better than one general-purpose interface Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.
Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing? 2. Can you make a build in one step? If it takes 20 steps to compile the code, run the installation builder, etc., you're going to go crazy and you're going to make silly mistakes. we required that the installation process be able to run, from a script, automatically, overnight, using the NT scheduler, and WISE couldn't run from the scheduler overnight, so we threw it out. (The kind folks at WISE assure me that their latest version does support nightly builds.) 3. Do you make daily builds? Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source. 4. Do you have a bug database? complete steps to reproduce the bug expected behavior observed (buggy) behavior who it's assigned to whether it has been fixed or not
If the complexity of bug tracking software is the only thing stopping you from tracking your bugs, just make a simple 5 column table with these crucial fields and start using it.
Spaghetti code is a pejorative term for source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled. pejorative a word or expression that is pejorative is used to show disapproval or to insult someone http://en.wikipedia.org/wiki/Spaghetti_code
Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server,
serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations.
With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.
Static program analysis is the analysis of computer software that is performed without actually executing programs (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code.
The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding, program comprehension or code review.
http://en.wikipedia.org/wiki/Static_program_analysis
Agile is all the buzz these days. With Agile, analysis is done similar to the Waterfall method. However, once analysis is done, each requirement is prioritized as follows:
High- These are mission critical requirements that absolutely have to be done in the first release.
Medium- These are requirements that are important but can be worked around until implemented.
Low- These are requirements that are nice-to-have but not critical to the operation of the software.
Features:
Entire application is broken into pieces called iteration.Each iteration is an increase in the functionality
Active customer involvement;every iteration is tested and approved by client
Priority based delivery:high priority feature is developed first.After each iteration project priorities are re-evaluated
People-centric:documentation and other non-development activities are minimized and more time is devoted to testing and development.
Below are the advantages of the Agile Iterative Life Cycle:
The Design phase goes much faster, as designs are only done on the items in the current release (Release 1.0 for example).
Coding and Testing go much faster because there are less items to code and test. If major design flaws are found, re-work is much faster since the functional areas have been greatly reduced.
The client gets into production in less than 3 months, allowing them to begin earning revenue or reducing expenses quicker with their product.
If market conditions change for the client, changes can be incorporated in the next iterative release, allowing the software to be much more nimble.
As the software is implemented, the client can make recommendations for the next iteration due to experiences learned in the past iteration.
Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches.
Agile processes use feedback, rather than planning, as their primary control mechanism.
The feedback is driven by regular tests and releases of the evolving software.
Extreme Programming (XP)
Scrum
Dynamic systems development method
Code and fix
Agile Programming Introduction - Software Development Tutorial
Face to face communication and continuous inputs from customer representative leaves no space for guesswork.
The documentation is crisp and to the point to save time
The end result is the high quality software in least possible time duration and satisfied customer
Agile methodology has an adaptive team which is able to respond to the changing requirements.
you can get development started fast, project scope statement is "flexible" and not fully defined.
Disadvantages of Agile Methodology
There is lack of emphasis on necessary designing and documentation.
The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources
The literal meaning of the word agile, an adjective, is “Characterized by quickness, lightness, and ease of movement.”
So this indicates that Agile Software development is about fast delivery of software with more ease of development
Key Features of Agile Software Development
Iterative: Entire application is distributed in incremental units called as iteration. Development time of each iteration is small (couple of weeks), fixed and strictly adhered to. Every Iteration is a mini increment of the functionality and is build on top of previous iteration
Active Customer involvement: There is lot of client involvement and face-to-face interaction. Every iteration is tested and approved by client. thus minimizing risk and ensuring higher client satisfaction
Fixed Time: Each iteration has a fixed time span in which it is delivered.
Empowered Teams: The project teams are generally small and have lot of interaction and communication
The documentation and other non-development activities are minimized and more time is devoted to development and testing
Benefits to the Customer
Customer is more actively involved, and gets higher priority
He gets to know regular and frequent status of the application
Requirements are accepted after each iteration
Benefits to the Project Teams
Since the development is Incremental, teams can focus on the specific requirements at any given point of time
More emphasis is on developing the application only, and not on documentation. Simple and minimal documents are used to exchange the views
Less time is spent in gathering requirements as all the requirements are not gathered upfront and are implemented as and when they arise
So less time is required for planning.
Less cost of development as rework, management, documentation and other non-development work related cost is reduced
Project Management implies a start and end date, while Scrum in contrast focuses on sustaining a product.
The guide defines the purpose of Scrum as: “a framework for developing and sustaining complex products”.
The modern trend as espoused by the DevOps movement is that the team that builds the software also runs the software. In the past we normally developed a software project using a project management methodology and then an operations team took over the maintenance and operation of it. Traditional IT models divide implementation and support into separate teams, sometimes referred to as “build” and “run” or “development” and “support”.
As the Scrum Guide states: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team”.
https://langerman.co.za/agile_pm_harmful/
Manifesto for Agile Software Development
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org/
Twelve Principles of Agile Software
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. http://agilemanifesto.org/principles.html
ALM (Application Lifecycle Management)
Practices in ALM can be grouped into three areas: Governance Development Production Within each area, the following practices can be applied to any development team’s ALM strategy: Requirements gathering. Project management tools. Source control. Defect tracking. Automated testing and more. Agile is not a silver bullet. It is a better way of developing software. So, making sure that individuals on the team interact frequently and do not rely on the tools over the interactions is one way to ensure that your ALM practice is Agile. For Agile teams, while comprehensive project plans can help to coordinate large initiatives, most planning takes the form of release plans with stories Using reporting mechanisms like burn down charts (release burn down charts show the progress of the team), velocity charts, and cumulative flow diagrams helps teams plan. Planning also happens in a more collaborative way using Agile methods. Scrum, XP, Sprint, or iteration planning sessions allow the team to plan and commit to what they will get done within a fixed amount of time these tools support Agile methods: Pivotal Tracker Version One Rally Lean Kit Kanban Microsoft ALM IBM Rational How Agile ALM Improves Requirements Gathering Agile teams rely on smaller scoped work items in their requirements gathering. Most teams utilize user stories to convey features that need to be built. The easiest ALM tool one could use for basic requirements gathering is index cards on a big board. Using a board and index cards is a great way for a team to begin a project Other types of requirements include acceptance criteria. In Agile teams — as in most teams — these take the form of wireframes, mockups, and some written format The Role of Version Control in Agile ALM So you should establish a branching and merging strategy for your team. This is not necessarily an Agile-only ALM practice; it is necessary for any ALM implementation Quality Assurance in Agile ALM In an Agile ALM solution, this includes Test Driven Design or Test Driven Development (TDD). So automated unit tests are necessary, along with the ability to have some metrics on those automated tests Teams must perform code reviews through pair programming or some other mechanism to determine that automated acceptance criteria can be used for quality checks as well. Some teams use tools for Behavior Driven Development (BDD), which can help in this regard too. QA Tools Below is a partial list of tools that support Agile methods that can be utilized for quality assurance: Cucumber RSpec NUnit JUnit Raconteur DevOps in Agile ALM The DevOps approach encourages greater collaboration between the development team and the infrastructure departments, in particular the operations group. ALM practices work well with the DevOps concept because they prescribe stable, consistent development environments that help assure product quality and seamless deployment This is critical to the DevOps concept, which includes a build system that takes the source control and builds and deploys it in a consistent manner on each environment.
Agile Application Lifecycle Management (Agile ALM) is a central platform that allows teams using Agile methods, alone or in combination with other development methodologies (e
.g., RUP, waterfall), to manage all phases of the software development lifecycle from requirements through release. By uniting business users and developers and providing cross-team visibility, Agile ALM enables organizations to achieve a faster time to market and higher-quality software releases while reducing infrastruc ture costs.
Agile ALM is the practice of using Agile processes to manage your requirements, issues, and tests.
Applying Agile to ALM helps you: Deliver quality releases quickly. Improve collaboration across teams. Prioritize customer needs. Agile is all about value and people. And ALM is all about tools. Individuals and Interactions Over Processes and Tools. Traditional ALM is often governed by steps for completing the product. First you gather requirements. Then you build the product. And then you run tests. This can create silos by process. Agile ALM, instead, favors cross-functional team interaction. Gathering requirements is a collaborative process — and these requirements are reviewed and updated constantly. The product is built and tested in sprints, facilitating greater collaboration throughout the process. Working Software Over Comprehensive Documentation. ALM is traditionally characterized by extensive documentation. Agile suggests prioritizing fast (quality) releases over documentation. Hybrid Agile typically bridges the gap for organizations who need the documentation (e.g., for compliance) but want to be Agile. Customer Collaboration Over Contract Negotiation. In traditional ALM, customer feedback comes in the form of requests for bug fixes or features. It usually doesn’t inform requirements. In Agile ALM, customer feedback is critical. It’s often included in requirements gathering throughout the development lifecycle. Responding to Change Over Following a Plan. Traditional ALM is all about the plan. The plan is set firmly at the beginning of development and followed through to deployment. Agile ALM responds to change. The plan — if you call it that — is in flux. This helps team members be more productive and deliver the right functionality at the right time. And that typically helps you reduce your costs.
Traditionally, companies have used the Waterfall methodology. The
Waterfall methodology performs each phase of the software lifecycle
sequentially:
The team creates a list of all requirements before any
design is done.
Upon requirements completion, a detailed design is
created for each requirement.
Upon design completion, all tasks are estimated and
submitted for approval.
Upon approval, coding begins and test cases are created
in preparation for quality assurance.
Upon code completion, testing begins and continues
until all test cases are run and all defects are fixed.
Upon quality assurance completion, the software is
documented and moved to production.
The
advantage of Waterfall is that it is a very disciplined methodology, producing
very detailed specifications that can be translated to user and technical
documentation. It also provides very detailed oversight, including continual
risk management and disciplined project management planning and measurement. The
disadvantage of the Waterfall methodology is that it takes a long time to
deliver software to production (normally more than a year). The reason is due
to the effort involved in defining all features of the software and creating
detailed designs for all of them. It is also problematic because if major flaws
are found in the requirements or design, it does not appear until the testing
phase, and reworking a flawed design adds risk to the project as well as a lot
of effort. Last, because the duration of Waterfall tends to span a year or
more, business rules and needs can change, and the original design of the
software may not still apply, making features of the new software obsolete
before it ever makes it to production
In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code. code obeying the principle doesn't change when it is extended, and therefore needs no such effort. http://en.wikipedia.org/wiki/Open/closed_principle
The key characteristic of a Spiral model is risk management at regular stages in the development cycle
Iterative and incremental development
Iterative development prescribes the construction of initially small but ever-larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.
Agile development
Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches.
Agile processes use feedback, rather than planning, as their primary control mechanism.
The feedback is driven by regular tests and releases of the evolving software.
Extreme Programming (XP)
Scrum
Dynamic systems development method
Code and fix
Yazılım Süreci Modelleri
Süreçlere ilişkin ayrıntılarla ya da süreçler arası ilişkilerle ilgilenmezler.
Gelişigüzel Model
Barok Modeli
Çağlayan (Şelale) Modeli
V Modeli
Helezonik (Spiral) Model
Evrimsel Model
Artırımsal Model
Araştırma Tabanlı Model
https://docs.google.com/viewer?a=v&q=cache:h-uE4oVxKEkJ:metinakbulut.com/YAZILIM-MIMARISI/Bolum-02.ppt+&hl=en&pid=bl&srcid=ADGEESiVmUq28rel_uDufGt4hTrHCQJobcQWjz1uLDTfP1KdtLjfuTx16UMDgoKfKVPxsiUCvkMgGprNKDLuAGHyg7PCCwpQVsYqL4dIMBrwbjyYjc7-5SZ7k3i8lZk811DWSUMNY6pU&sig=AHIEtbSNh8MipDzJioe4jerIIEKNlu6IWQ
Software process models:
Waterfall model
Evolutionary development
Formal systems development
Reuse-based development
Hybrid software process models:
Incremental development
Spiral development
https://docs.google.com/viewer?a=v&q=cache:mzUVIL-enOoJ:ranger.uta.edu/~khalili/Chapter%25202%2520-%2520Software%2520Processes.ppt+&hl=en&pid=bl&srcid=ADGEESi6A2gA72cNC8G9XZUGMFbdp_KiBVyfImtHJ5fQkFFx5gMfiay2PqBy8dPVIWC2LtNxTJmKtyDsEOV1o0xzG5FK15XLMvuz7r7yw1wAGdU-cHsxsaSBTnIsUbh3sEaUXd8-VxQz&sig=AHIEtbTW9RfBAQsoyIn3uwsmbqdgsKu8rA
the key pros and cons of six of the most common SDLC methodologies
1. Waterfall Model
Waterfall is the oldest and most straightforward of the structured SDLC methodologies — finish one phase, then move on to the next. No going back. Each stage relies on information from the previous stage and has its own project plan.Waterfall is easy to understand and simple to manage. But early delays can throw off the entire project timeline. And since there is little room for revisions once a stage is completed, problems can’t be fixed until you get to the maintenance stage. This model doesn’t work well if flexibility is needed or if the project is long term and ongoing.
2. V-Shaped Model
Also known as the Verification and Validation model, the V-shaped model grew out of Waterfall and is characterized by a corresponding testing phase for each development stage. Like Waterfall, each stage begins only after the previous one has ended. This model is useful when there are no unknown requirements, as it’s still difficult to go back and make changes.
3. Iterative Model
Instead of starting with fully known requirements, you implement a set of software requirements, then test, evaluate and pinpoint further requirements. A new version of the software is produced with each phase, or iteration. Rinse and repeat until the complete system is ready.One advantage over other SDLC methodologies: This model gives you a working version early in the process and makes it less expensive to implement changes. One disadvantage: Resources can quickly be eaten up by repeating the process again and again.
4. Spiral Model
the Spiral model takes a cue from the Iterative model and its repetition; the project passes through four phases over and over in a “spiral” until completed, allowing for multiple rounds of refinement. This model allows for the building of a highly customized product, and user feedback can be incorporated from early on in the project. But the risk you run is creating a never-ending spiral for a project that goes on and on
5. Big Bang Model
the Big Bang model follows no specific process, and very little time is spent on planning. The majority of resources are thrown toward development, and even the client may not have a solid grasp of the requirements. This is one of the SDLC methodologies typically used for small projects with only one or two software engineers.
6. Agile Model
By breaking the product into cycles, the Agile model quickly delivers a working product and is considered a very realistic development approach. The model produces ongoing releases, each with small, incremental changes from the previous release. At each iteration, the product is tested.
This model emphasizes interaction, as the customers, developers and testers work together throughout the project. But since this model depends heavily on customer interaction, the project can head the wrong way if the customer is not clear on the direction he or she wants to go.
https://www.roberthalf.com/technology/blog/6-basic-sdlc-methodologies-the-pros-and-cons
Structured programming codes includes sequencing,alteration and iteration
Structured programming is a programming paradigm aimed on improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures and for and while loops - in contrast to using simple tests and jumps such as the goto statement which could lead to "spaghetti code" which is both difficult to follow and to maintain.
Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects.
Each object is characterised by its class, its state (data elements), and its behavior
What is OOAD? To emphasize considering a problem domain and logical solution from the perspective of objects
OOA
Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system
OOA focuses on what the system does
Object-oriented analysis (OOA) is the process of analyzing a task (also known as a problem domain), to develop a conceptual model that can then be used to complete the task
A typical OOA model would describe computer software that could be used to satisfy a set of customer-defined requirements
During the analysis phase of problem-solving, a programmer might consider a written requirements statement, a formal vision document, or interviews with stakeholders or other interested parties.
The conceptual model that results from OOA will typically consist of a set of use cases, one or more UML class diagrams, and a number of interaction diagrams.
OOA :to find and describe the objects in the problem domain
OOD
Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications
OOD on how the system does it.
During object-oriented design (OOD), a developer applies implementation constraints to the conceptual model produced in object-oriented analysis
Concepts in the analysis model are mapped onto implementation classes and interfaces resulting in a model of the solution domain
