Table of contents
Methodology: A systematic way of doing something
Ad hoc: for or concerned with one specific purpose
Software Engineering methodologies were developed in response to the ad hoc development processes of the 60s and 70s.
There are many to choose from:
- Functional Decomposition Methods
- Based on functional decomposition and stepwise refinement; the breaking down of complex systems into single-function tasks and subtasks.
- Data Structured Methods
- Used for systems that tend to be mostly databases and the modification of how that data was presented to the user
- Formal Methods
- Are mathematically-based techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analyses can contribute to the reliability and robustness of a design
- Object-Oriented methods
Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agility- rapid and flexible response to change.
· The purpose of modeling and models is primarily to support understanding and communication, not documentation.
· Don't model or apply the UML to all or most of the software design. Defer simple or straightforward design problems until programming.
· Use the simplest tool possible. Prefer "low energy" creativity-enhancing simple tools that support rapid input and change. Also, choose tools that support large visual spaces. For example, prefer sketching UML on whiteboards, and capturing the diagrams with a digital camera.\
· Don't model alone, model in pairs (or triads) at the whiteboard, in the awareness that the purpose of modeling is to discover, understand, and share that understanding. Rotate the pen sketching across the members so that all participate.
· Create models in parallel. For example, on one whiteboard start sketching a dynamic-view UML interaction diagram, and on another whiteboard, start sketching the complementary static-view UML class diagram.
· Use "good enough" simple notation while sketching with a pen on whiteboards. Exact UML details aren't important, as long as the modelers understand each other.
· Know that all models will be inaccurate, and the final code or design differentsometimes dramatically differentthan the model. Only tested code demonstrates the true design; all prior diagrams are incomplete hints, best treated lightly as throw-away explorations.
· Developers themselves should do the OO design modeling, for themselves, not to create diagrams that are given to other programmers to implement- an example of un-agile waterfall-oriented practices.
Avoid processes/tasks which discourage change.
- Long release cycles
General Practice of XP
- Business decides about
- Composition of releases
- Dates of releases
- Technical people decide
- Detailed scheduling
- Small Releases
- Simple Design
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40 Hour Work Week
- On-Site Customer
- Coding Standards
- Requirements are captured using "User Stories"
- Each User story has an acceptance test
- Planning is a cooperative exercise or determining priorities
1- Iterative and Incremental
The Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations. (The Inception phase may also be divided into iterations for a large project.) Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release. Although most iterations will include work in most of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.
2- Use Case Driven
In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.
3- Architecture Centric
The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views. One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.
"An architecture is the identification of the components of a system, their relationships and their organization. An architecture supports the goals of a system and respects the constraints. An architecture identifies the critical issues and makes explicit the design choices made.”
4- Risk Focused
The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.
Uses UML as the notation for documentation
- Inception - approximate vision, business case, scope, vague estimates
- Elaboration - refined vision, iterative implementation of core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, timeboxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost.
- Construction - iterative implementation of the remaining lower risk and easier elements, and preparation for deployment
- Transition - beta tests, deployment
Schedule-oriented terms in the UP
Follows 80/20 rule: Deliver 80% functionality in 20% of the time.
- Feasibility study
- Business study
- Functional model iteration (Incremental prototyping)
- Design and Build iteration
- Small working teams are organized to maximize communication and minimize overhead. Teams share information knowledge
- Frequent releases
- Constant testing and documentation
- Backlog: a prioritized list of project requirements or features which provide business value to the customer
- Sprints: consist of work units that are required to achieve a requirement defined in the backlog. Defined time period (typically 30 days)
- Scrum Meetings: A short meeting every day (typically 15 minutes) where each of the team members answers three questions
- What did I do since the last meeting?
- What obstacles are you encountering?
- What do you plan to accomplish by the next meeting?
- Demos: deliver the software to the customer so that the functionality which has been implemented can be assessed. A demo may not contain all of the planned functionality. It only contains the functionality which could be implemented in the sprint.
The "scrum master" leads the meetings and assesses the responses from each person. The meeting attempts to uncover potential problems as early as possible.
A feature is a client-valued function that can be implemented in two weeks or less.
The emphasis on features has the following benefits:
- They are small and can be easily described by users
- They can be organized into hierarchical business-related groups
- Team delivers new features every 2 weeks
- Because features are small, their design and code representations are easier to inspect effectively
- Project planning, scheduling, and tracking are driven by feature hierarchy rather than an arbitrary adopted software engineering task set.
FDD has five processes. The first three are done at the beginning of the project.
- Develop an Overall Model
- Build a Features List
- Plan by Feature
The last two are done within each iteration.
- Design by Feature
- Build by Feature
Developers are put into 1 of 2 categories: Chief Programmers and Class owners
Chief programmers are assigned features to build. They, however, do not build them alone. They coordinate class owners who build much of the feature.