jump to navigation

SDLC Models January 28, 2008

Posted by Coolguy in Software Development.
  • Agile: Iterations. Has planning, analysis, development, etc. Timeboxed
  • RAD:  Prototyping
  • Waterfall: Sequential
  • XP: Agile method for rapid development
  • Scrum : Project management for Agile
  • Iterative: Incremental development.

RUP August 26, 2005

Posted by Coolguy in Software Development.
add a comment

The Rational Unified Process is a Software Engineering Process.

The goal of RUP is to ensure the production of high-quality software that predictably meets the needs of its end users on schedule and within budget.

It provides a disciplined approach to assigning tasks and responsibilities within a development organization and has been applied to projects of varying size and complexity, with small teams and large, and with durations lasting weeks to years.

Phases in a Project August 26, 2005

Posted by Coolguy in Software Development.
add a comment

Project Start Up Phase: An idea for a project is agreed in principal by one or more Business Stream Technology Councils. Service Delivery will work with members of the affected Business Streams to outline a Business Case and requirements for a project. A Project Steering Group is assigned to run the project to conclusion.

Project Initiation Phase: The project will then be elaborated to the point where a reasonably confident view of the project: its specifications, timescales, budget and success criteria can be agreed.

Construction Phase: The project is then built in a number of demonstrable stages. The progress and quality of the project is formally reviewed by the Project Steering Group after each stage.

User Acceptance Phase : At the end of construction, user testing is performed to ensure that the result of the project fulfils the agreed specification. (See User Acceptance Phase.)

Deployment Phase: A deployment phase then tests the outcome in practice and gets it into live usage.

Project Closure Phase: Finally, the Project Steering Group and the Project Sponsor agrees that a project is complete and can be closed down.

Classic Mistakes in Software Development August 25, 2005

Posted by Coolguy in Software Development.
add a comment


  • Undermined motivation
  • Weak personnel : Who could be hired fastest instead of who would get the most work done over the life of the project
  • Uncontrolled problem employees : Failure to take action to deal with a problem employee
  • Heroics: Elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting
  • Adding people to a late project
  • Noisy, crowded offices
  • Friction between developers and customers : Customers may feel that developers are not cooperative when they refuse to sign up for the development schedule that the customers want, or when they fail to deliver on their promises. Developers may feel that customers unreasonably insisting on unrealistic schedules or requirements changes after requirements have been baselined
  • Unrealistic expectations
  • Lack of effective project sponsorship: High-level project sponsorship is necessary to support many aspects of rapid development including realistic planning, change control, and the introduction of new development practices
  • Lack of stakeholder buy-in. All of the major players in a software-development effort must buy in to the project
  • Lack of user input
  • Politics placed over substance
  • Wishful thinking: Wishful thinking isn’t just optimism. It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will


  • Overly optimistic schedules
  • Insufficient risk management
  • Contractor failure
  • Insufficient planning
  • Abandonment of planning under pressure
  • Wasted time during the fuzzy front end : The “fuzzy front end” is the time before the project starts, the time normally spent in the approval and budgeting process
  • Shortchanged upstream activities: Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture, and design don’t directly produce code, they are easy targets.On one disaster project that I took over, I asked to see the design. The team lead told me, “We didn’t have time to do a design.”
  • Inadequate design
  • Shortchanged quality assurance: Design reviews and code reviews were given short shrift in order to achieve a perceived schedule advantage
  • Insufficient management controls
  • Premature or too frequent convergence
  • Omitting necessary tasks from estimates
  • Planning to catch up later
  • Code-like-hell programming


  • Requirements gold-plating: Some projects have more requirements than they need right from the beginning. Performance is stated as a requirement more often than it needs to be, and that can unnecessarily lengthen a software schedule. Users tend to be less interested in complex features than marketing and development are, and complex features add disproportionately to a development schedule
  • Feature creep: Even if you’re successful at avoiding requirements gold-plating, the average project experiences about a 25-percent change in requirement over its lifetime
  • Developer gold-plating: Developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product–whether or not it’s required in their product
  • Push me, pull me negotiation: One bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that’s progressing slower than expected and then adds completely new tasks after the schedule change
  • Research-oriented development: Software research schedules are not even theoretically predictable


  • Silver-bullet syndrome: When project teams latch onto a single new methodology or new technology and expect it to solve their schedule problems, they are inevitably disappointed
  • Overestimated savings from new tools or methods
  • Switching tools in the middle of a project
  • Lack of automated source-code control

Extreme Programming August 2, 2005

Posted by Coolguy in Software Development.
Tags: ,
add a comment
  • The main aim of XP is to lower the cost of change.
  • In traditional system development methods the requirements for the system are determined at the beginning of the development project and often fixed from that point on.
  • This means that the cost of changing the requirements at a later stage in the projectc will be very high.
  • XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes
  • Risky projects with dynamic requirements are perfect for XP
  • XP is set up for small groups of programmers.You can not use XP on a project with a huge staff
  • XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well.

XP core practices
12 core practices of XP are as follows:

  • Test driven development : Within XP, unit tests are written before the eventual code is coded
  • Planning game
  • Onsite customer: XP says that the customer should be at hand at all times and available for questions
  • Pair programming : Pair Programming means that all code is produced by two people programming on one task on one workstation.
  • Continuous Integration
  • Refactor: Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck
  • Small Releases
  • Simple design
  • System metaphor
  • Collective code ownership
  • Coding standards

XP values
The five values are:

  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect (the latest value)


  • A fundamental task of building software systems is communicating system requirements to the developers of the system.
  • In formal software development methodologies, this task is accomplished through documentation
  • Extreme Programming favors simple designs, metaphor, collaboration of users and programmers, frequent verbal communication and feedback.
  • Unfortunately, XP also makes a big issue about not doing any documentation (or at least very little, or none at all).


  • eXtreme Programming encourages starting with the simplest solution and refactoring to better ones
  • The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow
  • XP promotes a throwaway approach to source code (i.e. write, toss, rewrite).
  • A simple design with simple code can be easily understood by every programmer in the team


  • Feedback from the system: by writing unit tests the programmers have direct feedback from the state of the system after implementing changes.
  • Feedback from the customer: The functional tests are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
  • Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement


  • Courage enables developers to feel comfortable with refactoring their code when necessary.
  • This means reviewing the existing system and modifying it so that future changes can be implemented more easily
  • Another example of courage is knowing when to throw code away

Activities of XP

XP describes four basic activities that are performed within the software development process

  • Planning
  • Coding
  • Designing
  • Testing


  • The main planning process within eXtreme Programming is called the planning game.
  • The planning process is divided into two parts
    • Release Planning
    • Iteration Planning
  • Typical activities in planning process are:
    • User stories are written.
    • Release planning creates the schedule.
    • Make frequent small releases.
    • The Project Velocity is measured.
    • The project is divided into iterations.
    • Iteration planning starts each iteration.
    • Move people around.
    • A stand-up meeting starts each day.
    • Fix XP when it breaks

Release Planning:

  • This is focused on determining what requirements are included in which release and when it’s going to be delivered.
  • The customers and developers are both part of this
  • Release Planning consists of three phases
    • Exploration Phase: In this phase the customer will give all his requirements for the system. These will be written down on user story cards.
    • Commitment Phase:Within the commitment phase business and development will commit themselves to the functionality that will be included and the date of the next release
    • Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and or existing requirements can be changed or removed.

Exploration phase – Release planning

  • This is an iterative process of gathering requirements and estimating the work impact of each of those requirements
  • Get Requirement from Customer: In this phase the customer will give all his requirements for the system. Business has come with a problem; during a meeting, development will try to define this problem and get requirements. These will be written down on user story cards.
  • Write a Story: Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story for so far the functionality. The story is written on a so called user story card.
  • Split a Story: If development isn’t able to estimate the story (next item), it needs to be split up and written again. Again, this may not influence the business requirements
  • Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.

Commitment Phase – Release planning

  • This phase involves the determination of costs, benefits, and schedule impact. It has four components.
  • Sort by Value: Business sorts the user stories by business value. Critical,Significant Business Value,Nice to have.
  • Sort by Risk: Development sorts the stories by Complexity,Volatility,Completeness
  • Set Velocity: Development determines at what speed they can perform the project. Programming Units. 1 Unit = X Man days
  • Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined

Steering phase – Release planning

  • Within the steering phase the programmers and business people can “steer” the process.
  • That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong.
  • This is the chance to adjust the plan accordingly.

Iteration Planning:

  • This plans the activities and tasks of the developers.
  • In this process the customer is not involved. Iteration Planning also consists of three phases:
    • Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards
    • Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
    • Steering Phase: The tasks are performed and the end result is matched with the original user story.

Exploration phase – Iteration planning

  • The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.
  • Gather User Stories: Gather and write all user stories for the next release
  • Combine/Split task: If the programmer cannot estimate the task because it is too big or too small, the programmer will need to combine or split the task.
  • Estimate task: Estimate the time it will take to implement the task.

Commitment phase – Iteration planning

  • Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.
  • A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
  • Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
  • Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
  • Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.

Steering phase – Iteration planning

  • The implementation of the tasks is done during the steering phase of the iteration planning.
  • Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
  • Find a Partner: The programmer will implement this task along with another programmer. This is further discussed in the practice Pair Programming.
  • Design the task: If needed, the programmers will design the functionality of the task.
  • Write unit test: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.
  • Write code: The programmers start to code.
  • Run test: The unit tests are run to test the code.
  • Refactor: Remove any code smells from the code.
  • Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.


  • Simplicity : A simple design always takes less time to finish than a complex one.
  • Choose a system metaphor :Choose a system metaphor to keep the team on the same page by naming classes and methods consistently
  • Use CRC cards for design sessions:Individual CRC Cards are used to represent objects.
  • Create spike solutions to reduce risk : Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions.
  • No functionality is added early : Keep the system uncluttered with extra stuff you guess will be used later
  • Refactor whenever and wherever possible: Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend.


  • The customer is always available : All phases of an XP project require communication with the customer, preferably face to face, on site.
  • Code must be written to agreed standards : Code must be formatted to agreed coding standards
  • Code the unit test first.
  • All production code is pair programmed.
  • Only one pair integrates code at a time.
  • Integrate often : Developers should be integrating and releasing code into the code repository every few hours, when ever possible.
  • Use collective code ownership.
  • Leave optimization till last.
  • No overtime.


  • All code must have unit tests.
  • All code must pass all unit tests before it can be released.
  • When a bug is found tests are created.
  • Acceptance tests are run often and the scoreis published: The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.

XP Roles

  • Customer
    • The on-site customer (or customer team) is there to make day-to-day business decisions about what functionality goes into the project and what stays out.
    • The programmers and the XP Coach lead the customer by the hand
  • Programmer
    • XP requires programmers to have a broader skill set than simply programming. Suddenly they are not only coders but customer-facing analysts
  • Tester
    • Programmers perform unit testing, and either the programmers or the customer perform acceptance testing

Controversial aspects

  • Detailed specifications are not created or preserved
  • Programmers are required to work in pairs – not all software developers expect to be asked to work this way
  • A customer representative is attached to the project. This role can become a single-point-of-failure for the project and some people have found it to be a source of stress

More info:


Step Four: Software selection July 31, 2005

Posted by Coolguy in Software Development.
add a comment

At the start of the selection process you should determine what the exact criteria are for selecting a certain piece of software.

  • Project budget
  • Inhouse expertise
  • Functionality : Check features catalogue
  • Reliability
  • Security: Check security bulletin
  • Compatibility
  • Operational Support: Is training needed ?
  • Future Proofing: Is it being actively developed ?
  • Total cost of Ownership: Are there any metrics available ?
  • Stability of the vendor/community
  • Proven track record: Sucess stories ?
  • Fit-for-purpose with least possible changes to the standard software as possible
  • Maturity: First release date
  • Maintainability

Step Three : Architechture July 31, 2005

Posted by Coolguy in Software Development.
add a comment

Step One : PBS July 31, 2005

Posted by Coolguy in Software Development.
add a comment

Indentify all the products to be delivered.
Leave as Application Software.
Revised as necessary.

Step Two: PFD July 31, 2005

Posted by Coolguy in Software Development.
add a comment

Determine the sequence of products to be delivered.

Best Practices for Software Development Projects January 18, 2005

Posted by Coolguy in Software Development.
Tags: ,
add a comment

Best Practices for Software Development Projects