Documentation with a Software Project

How a project design is getting documented in the SSDs, the operation contracts, the class diagrams, the sequence diagrams, and the communication diagrams?

The more documentation the better to help future developer maintain and upgrade the code. Many people who might be part of the project might not have a coding background but will need to understand what is being implementing and how to stage the project.


What is the team that documents are also doing the coding?

It would depend on the size of the team and scope of the project. It the team changes or new people join the team they will need to get up to speed on which stage the project is and what their part would be. Also, if there is an error in project and the developer is no one with the project, the new document available will help any future developer to understand and fix and broken parts to the code.


Do you think it is overkill if these documents are sent overnight to offshore, and code returned the next morning, as a regular part of the development process?

It’s not overkill be would it depend on the reason behind sending the code to a remote team. Also, it would be depending on the how detailed and organized the documents are. If there is an error in the logic or implementation the returned code would have minimal or no benefit on the project or module. This is the return for sandbox testing and staging development

Domain Model vs. Design Model

A domain model is a conceptual model and solution independent. This resulting from a domain and requirements in system analysis, or inception, phase of a development project. This will provide visual representation of the class within the domain, basic relationship between domain classes, and any key attributes of the class. Domain models are also called:

  • Conceptual models
  • Domain object models
  • Analysis Object Models

Using a domain model creates a blueprint saving time by help the design team will gain a better understanding of the system requirements reducing complexity, testing, maintainability. The system will have less bugs and better meet user requirements faster within the project timeline.

Domain Model

A design model is a logical model and platform independent resulting from system design activities in the elaboration phase. This will describe how everything works together, are connected, and interact with each other. design model.

Design Model

Use cases and capturing functional requirements in system

Being able to capture all the functional requirements a case might have would depend the item the class is representing. Some real work items a developer or team might be able to predict any behavior or states it might have at any given time or sets or time, other item might be more difficult. There is always unforeseeable behaviors and states of any system where the development team will actively update a system accommodate such states or behavior. Also, human error is always a factor when developing a system when sometime anything can and will happen.

A simple use case for a finite-state machine can be in exactly one of a finite number of states at any given time. Example: a turnstile is a gate with three rotating arms at waist height, one across the entryway. Initially the arms are locked preventing a person from passing through. Depositing a token in a slot on the turnstile unlocks the arms, allowing a single person to push through. After they passes through, the arms are locked again until another coin is inserted. Developing a use case becomes increasingly more difficult to implement for non-deterministic finite automaton where a machine can move to any combination of the states in the machine. Thus, the exact state to which the machine moves cannot be determined

Functional requirements that might not be able to document using UML and Activity diagrams would be unknown input sources, unexpected event, or human error. One or all these factors may present themselves depending on what functions, scale, and scope of the system. Some requirements might be harder to anticipate, and document early in the development process. A good development team should always work with the client and/or user to anticipate any requirements and error which might occur.

Project Phases and Estimate

How accurate do you think an “order of magnitude” cost estimate should be?

A Rough Order of Magnitude (ROM) estimate is an unreliable estimate of the cost and effect to complete a project. This estimate is developed early in the project when there is a lack of detailed information. Some experts say the ROM estimate should be at least ±50% but can variety.


Can you compare and contrast a business case for a software project with a business case for replacing windows in a house where energy savings are being used as the reason for replacement?

Both cases would follow the normal project management steps, yet the risk and time line of each would depend on the size of each project. The tools used and skills required to for a software project are different then for replacing a window. After each project is complete there is the issue how much maintain it will require. A software project depending on the number of features and platform may require a on-going team to help maintain and fix bugs as they appear, where replacing a window may not require any maintained depending on the structure and natural factors.

Project Phase Software Project Replacing a Window

Show the need and return on investment

System doesn’t meet the needs of our users and/or environment Save money on energy bill or needs to be replaced

Create schedule, tasks, and allocate resources

System requirements, number of developer & testers, budget allocation How big is the window jam and vender selection; check the rough opening

Assign tasks to team member and paperwork

Create UML diagrams and assign development tasks How many people will it take to replace the window

Monitor progress and control changes

After end module is compete testers will ensure it works to specification Check for gaps, level, and squareness
Project Close

Closing paperwork & lessons learned

Launch the new system and deliver to users Clean area and verify installation

Agile Methodology vs. Waterfall Model

Waterfall project methodology


A model in which every stage of a product’s life cycle takes place in sequence and emphasizes a logical progression of steps. Before moving to the next phase, there is usually a review and sign off process to ensure that all defined goals have been meet. Ideal for projects that have a specific documentation and fixed requirements, estimated timeline, ample resources, and well understood technology.

7 non-overlapping stages

  1. Requirements
  2. Analysis
  3. Design
  4. Coding/Implementation
  5. Testing
  6. Operating/Deployment
  7. Maintenance


  • Upfront documentation and planning stages allow for large or shifting teams to remain informed and move towards a common goal
  • Forces structured and disciplined organization
  • Simple to understand, follow, and arrange tasks
  • Defines milestones and deadlines


  • Design is not adaptive to change
  • Delays testing until end of development life cycle
  • Does not consider error correction
  • Does not handle requests for change, scope adjustments or updates


Agile Methodology

1 Fzz56Ps_vQSTPHDO9IomXw.png

An approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-function teams and their customers/end users. Contains a set of different projects that are iterations of different stages; focused on improving the quality and feedback from users.


  • The client is involved throughout the project and can give feedback to change the product and its features as best suitable for the business and the client.
  • Change requests are easier to implement as the agile methodology follows an adaptive planning method, with plenty of room to accommodate change requests as they come.


  • Requires experience and quick decision-making ability to accept some changes and postpone other changes for the next sprint.
  • Does not work well if the client or the team does not understand agile methodology and could not keep up with the fast-paced environment.
Agile Waterfall
Iterations Stages
Constant Business Interaction Communication is varied between high/low iterations
Scrum master Project Manager
Can go back to previous iteration Cannot go back to previous stages
Increased speed Increased Quality
Flexible Structed and rigid