Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
We outsourced a web based portal and now we're not interested to work with them because the site is becoming more buggy day by day and increase of customers complain.
We've chosen a different team based on their local reputation and their portfolio are good to satisfy our urgent needs. We discussed this project with them and during a week they suggested some good ideas which help us to control. We are agreed to award this project to them. What I am thinking during the transition:
What documents do you think which can help new developers to understand the application? How many kinds of document I can request to them? If a new developers start working on it those documents help them to understand easily of all sides (application, database, configuration etc)
The application is on ASP.NET and SQL SERVER 2005 and the scariest part of all no source control tool is there. They do direct deployments without even push the publish button. Touch Luck :(
Thanks.
That's kind of hard to answer without knowing what kind of portal it is, but what comes to mind:
Owner's manual: Description of functionality, technologies used, full overview of all machines and services involved (don't forget data bases)
Backup: How and where is data backed up, where to restore it from in case of a crash
Description of all Databases used, relations between tables, at least quick rundown on what data is stored where
Links to any and all URLs to administration interfaces, tools, and scripts
Day-to-day operation: What cron jobs need to run frequently, are there caches, file lists or other things that need to be taken care of frequently
Make sure all domains used belong to you and are under your control
a description of the project's file structure (which part is where; where is the API; where are the visual elements; where are the front controllers)
How-To's on how to change the visual elements of the site (Style sheets, forms, templates...)
A description of any and all URL rewriting operations that take place in various parts of the systems, and where they point to
Which Google Analytics / Google Webmaster account is used and how to get hold of it
Ideally, an API documentation and full phpDoc style source code documentation
In addition to #Pekka's good answer I'd add the following
Functional Design Document (or
Business Requirements) - One that
explains how the application should
work from a business perspective.
Technical Specification (or
Architecture document) - One that
explains how the application was
developed from a technical
perspective.
Application Support
Guide - Some form of cheat sheet that
explains the common problems, service
accounts, batch schedules... etc
In addition to documentation you should be aware of the incident trends;
How may incidents?
How often?
How long do they take to resolve?
How many known defects are there?
Who maintains the infrastructure (patching OS, security audits, etc)
If you don't have enough technical resources to cover the daily number of incidents (keeping in mind there might be peak periods when usage of the portal is high) then you will probably find yourself in the same situation as your current service provider.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
From Estimation to Delivery - thoughout the software development life cycle,
Which all documents are involved and
What is the order?
I am not sure whether methodology have much impacts on documents, anyway let us consider Waterfall.
The answer is - as has been stated - it depends. I'm sure lots of people will answer for Agile methodologies (which are a far more movable feast) so for completeness I'll go with what you'd have for a fairly standard waterfall methodology:
A scope document - very high level outlining what is and more importantly what is not in scope of the project and what assumptions are being made. The main purpose of this document is to set expectations of what will ultimately be delivered - you're not saying how things will work but you're trying to answer questions such as will there be reporting? Will it pass data to other systems? Will you have to write your own user management functionality or pull from AD? Where you can't get definite answers to these things then include an assumptions section and list what you're assuming will be the case so people can correct you if you're wrong. It should also include things like target implementation dates (not as a commitment but so people know what is anticipated and manage expectations accordingly).
A functional specification - What the application should do on a business level. This can be divided out into business requirements (the business processes it's automating and how they work) and functional requirements (what the system does and how it does it - screen navigation, how calculations are made and so on) but more commonly they're combined except for the largest systems. It should also include "non-functional" requirements such as performance, load, security and so on.
A technical specification - The most likely to be missed out. A detailed technical design including things such as object models, schema diagrams and information on how detailed technical problems are being addressed.
Test plans and test scripts - How the application is being tested with detailed test cases, data and expected results, covering all elements of the system.
User guide and Release Notes - How to install, configure and use the application.
The one I'd add to this is a support document - a short (less than 10 pages) crash course in what the app does and how it does it. Developers will often not read the full specifications (either because they don't have time or don't want to) so this document should be enough to allow them to understand what it does, how it works, the areas of the application which are most likely to be problematic and so on. It would be written a few weeks after go live by the team who built and implemented the system.
Of course depending on your methodology you may have none of these documents but if you're running a standard project in an old school structured, waterfall way, this would be pretty normal.
I'll use the typical consulting answer... 'It Depends'.
To start, methodology has an enourmous impact on the documentation artifacts (not to mention project success), and I would place waterfall-style project management on the same level as allowing my doctor to cover me with leeches to cure a broken leg.
That being said - I have seen folks use the Microsoft Solutions Framework, and here's a link where you can grab their templates:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1&displaylang=en&displaylang=en
In reality, I would strongly recommend any project to use Agile methodologies and engineering practices (at least, if you want it to have a much higher chance of success than a waterfall project).
http://www.agilealliance.com/ has some good reading, as does wikipedia at http://en.wikipedia.org/wiki/Agile_software_development
Good luck!
In a typical production scenario, where the development is not carried out at the client location, generally waterfall model of SDLC is followed and documents pertaining to various stages of WFM are prepared:
Requirement gathering - Business Requirement Specification that details the complete requirement. This is functional in nature. This is accompanied by test case scenarios provided by users in which the users mention the testing and test cases that they would carryout on the desired functionality. This serves as a guideline to the development team as well to build the scope of the functionality and validations.
Requirement Analysis - During this phase, the BA associated with the project carried out the impact analysis and feasibility analysis. The limitations if any in the requirements, constraints, assumptions are documented, shared with the business users and signed-off to avoid any further surprises.
Development Approach - During this phase, the development team lead or the system analyst prepares an approach doc that defines the process flow, screen design, controls that will be placed on the screen, validations, attributes, database diagram, etc. This is then signed-off with the BA. If the development team foresee any technical constraint that will impact the desired functionality, same is shared with business team again and signed-off.
Testing - When the users carryout testing on the release, they validate the release based on the test cases and test scenarios provided earlier. The defects found are documented and sent back to the development team. The defects are first validated by the BA to ascertain whether the defect reported in understanding flaw, functional requirement lapse or technical bug. Accordingly resolution is provided. During this phase, care is taken that all the test cases are completed successfully and all the bugs are resolved. If any test case or bug is to be parked for next run, then basis the impact that it will have on the functionality, a joint call is taken by development team and business users on the risk involved. At the end, Business Users prepare testing sign-off document where they mention the time taken by each resource for testing, observations and process improvement suggestions.
Production Deployment - This includes the deployment instructions for the deployment team, server and database administrators to carryout deployment.
Feel free to provide your suggestions.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Web development is a mess.
This is because we have to interact with a lot of people.
Businness, Designers, Developpers, Leads, etc...
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
So, the question is, how do you work to make all those people understand themselves, interact together.
How could I decompose the severals steps leading to a website ?
Because a lot of enterprise sales a design at first, how could you then add the right functionnalities ?
For example, we can decompose a project like this :
Functional scopes (CRUD, Resources, ACL)
Designing the interface
Start development
Write xhtml/css according to the interface with the functionnal requirements
I may have forgotten steps, or disordered them.
EDIT :
For example, here is how I do :
I write a short overview about the project, what is the main goal ?
I try to know which resources (users, articles, products, etc..) are involved.
I write a short CRUD list for each resources which help me to have an overview about the features
I start to design the database (with mysql Workbench for example)
That done, i try to know if there are roles and privileges to rely them with the resources
I start development (+ testing)
Then i insert xhmtml code to respect W3C & web semantic.
I start to insert visual design with CSS
So what about you ? what are you steps to be efficient ?
I would say:
Overall Site Intent
User Analysis (Determine site/application Demographics, User Groups, etc.)
Conceptual Design
Graphic Design
Functional Scope
Interface Design (Prototype, Wireframes, etc.)
Interface Mockups
Development/Unit Testing
User Acceptance Testing
...pick and choose the parts you need. Doing all of them may be overkill, but probably not if you're working on a large team with many groups giving their input. Making sure you don't miss steps gives a chance for everybody to give their input and decide on a course of action.
Web development is different from other types of software development because frequently
there aren't any users among the development personnel. For example, "users" are absent from your list of people involved.
The users exist as a notional bunch of faceless people who are out there (we hope, because that's what the business plan is predicated on). Requirements are gathered and design decisions taken on the basis of assumptions about what the putative users might like or want.
So in many ways web development more resembles opening a restaurant or launching a new political party than rolling out an ERP system.
I don't think there's actually anything unique about web-development here compared to regular software development (with the exception of seo, which is just another technical challenge). I don't think there's anything inherently more "messy" about web-development. Read through the terms in your question again - do any of the terms (excluding seo as mentioned) not apply to general software development (substitute "xhtml/css" for "frontend development")?
Personally, I think any software engineering methodology which you've found works for your team-size/work environment/colleagues/etc is applicable to web-development.
There's nothing magical about the fact that the end-product runs in a browser.
XP and Agile methodologies look at creating teams whose members have all the skills needed for the project, such as Project Manager, developer, business anylist, designer, tester etc.
Having teams means there is better comunication between everyone involed including the client.
The subject is massive so do some google searches on XP, agie, scrum, kanban.
Yup dear you are right, there are several steps in developing a dynamic website however you want to develop a static site then its easy.
the only designing is needed for it and some functionality is added by a designer like email and so on.
but if you are going to develop a dynamic website then its accomplished by these steps.
1. First you make sure about the requirement.
2. Then you decide about its interface and layout.
3. Designer designed all the Form the are needed
4. Then the developer./ programmers will add functionality on froms .
5. After Completing the coding part the project goes to Testing for erros.
6.if any error occurs then it rectified by programmer again it goes to testing this process will going on until all error has not been removed.
7. Finally the web site publishes and then hosted on a server.
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
If you're really lucky you will have a team of talented multidisciplinarians who can take on more than one role.
That's when you tend to get the best web products.
Design by committee, which you will always get if everyone only gets to 'wear one hat', rarely produces kick-arse products.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am going to be starting a new job in a few weeks where I will be responsible for both the maintenance and development of a couple of existing web applications and the development of new web applications.
As I will be the only developer on the project and the previous developer was more of a hobbyist, no formal project management or planning techniques have been followed. Additionally no bug tracking has been used or if anything has been recorded its just been notes on paper.
I would therefore like to introduce a better system to help resolve some of the issues and help ensure things run more smoothly. I intend to develop using an agile process (likely scrum) and would therefore like to know what all-in-one solutions people could recommend for me to look into further. I am looking for something which will provide at minimum:
Project Planning
Defining new features
Time estimating
Ability to organise tasks by priority
Project Management
Tracking active tasks
Reporting
Bug Tracking
I would also like to let other staff easily submit new bugs in the applications which they find or customers report. Additionally support for them to add new stories / high level tasks would be of use so they can note down other new requirments/features and I can then work with them to outline more detailed tasks and estimates.
So far I have looked at a number of systems including:
FogBugz - Seems great for bug reporting but would need something else for project planning / management
Agile Buddy - This is probably the best solution I have found so far
Trac
Smart Sheets
Pivotal Tracker
However, as I have not actually used any of these systems myself I do not know what ones would be best or whether there is a better solution out there??? So any recommendations you can provide would be much appreciated.
Actually, FogBugz does project management as well. It will even try to learn how accurate time estimates for features are from each user, and give you estimated milestone completion times accordingly, with probabilities of finishing at various dates. I've used it for the bug tracking, and really liked it, but I've also read enough about its project management features to know that it has them, and they're pretty good.
FogBugz feature list
When I was working as a solitary developer, I picked up a copy of Planning Extreme Programming and bought a pack of 3x5 cards and a plastic box for them. I used those in the Planning Game and stuck the ones I was working on on my wall. My boss could walk by and see what I was working on. This worked well and cost little.
We're currently using Zen at work - it's a web-based Kanban board for planning. This is nice when your stakeholders aren't co-located or if priorities/requirements change frequently.
You can enter bugs as user stories with either system, or you could use a separate defect-tracking system.
I'd question if Scrum is suitable for a one-developer shop. It's targeted towards project management. I'd rather not have a stand-up meeting with myself. ;) XP (minus pair programming) works fine for a solitary developer.
For a one-man show, you don't need any tools to speak of.
Tools -- generally -- are for coordination.
If it's just you, what -- precisely -- are you coordinating?
If you want to make things visible, a pair of simple internally-focused web pages built from static content will do.
Bugs.
Burndown for Features.
That's about it. Use the simplest tools you can possibly use. I recommend using docutils to generate the HTML from plain, simple text.
Don't go tool-happy until you have a large enough team that simple text doesn't work any more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
At the place I am working we are moving to a more agile approach to project management.
For tool support for project management I used MS Project and Target Process in the past. But I think they both have serious weaknesses:
MS Project is not very intuitive and therefore hard to use especially for novice users. It doesn't really fit the agile approach
Target Process seems only half done. E.g. users can set their own privileges to admin. Size of user stories is measured in hours instead of a unitless size which I think is really a bad idea. The UI feels bloated and overly complicated not really supporting usage by keyboard only.
We are also using Jira for Issue Tracking and I guess one could modify it and add some custom fields/reports to make it an agile project management tool.
So my question is: What software tools do you use for agile project management and what do you like or dislike about it?
Addition: I am aware that physical tools like a whiteboard or post-its are in a sense the perfect tool but if you want to get an overview about what is going on in the complete company it is kind of cumbersome to run from office to office to look at the whiteboards or to force people to copy it in a different kind of document. A similiar argument applies if you are working in a setting where the customer is not on site.
I'll try to list some features I'd consider interesting:
easy accessible by management, customer, team potentially from different sites. This almost requires a web app.
option to configure the app to fit the flavor of agile preferred by the team or company
it should allow multiple people to access it in parallel. E.g. a developer marking a task/story as done, shouldn't block the customer from adding a new task. This pretty much rules out Excel.
Nice usability for keyboard only usage, at least for things like updating a lot of stories or adding a lot of stories
Ability to integrate with Jira (entries there should become tasks or something in the system, changes should get synchronized or at least be impossible if they don't get synchronized) and SVN (commit comments with a story id should appear in the tool)
Ability to integrate with other systems using a Java API.
Mostly we use whiteboards and post-its. If we have to use software we usually use Trac or a simple wiki.
It's our experience that using a project management tool actually makes your project less agile. The tool tends to become the focus point of the whole development process and its data more important than the actual software.
I can really recommend using a physical tool instead of a software one. It keep everybody focused in the same location and is much more public and accessible then even the simplest software equivalent.
There is value in using a tool to provide visibility into your agile project when it is not pragmatic to come to the team room. I would not recommend using a tool other than the big visible charts in the team room in place of the big visible charts. When a person has to go to a tool to pull the information as opposed to see the information continuously visible in the team room, it looses its effectiveness.
Of the tools we have used my comments are as follows
Mingle - Programmable and the most customizable, largest learning curve but you won't be boxed into a corner and the learning curve is quickly picked up by a developer
Rally - Does what you need it to out of the box. Enforces agile practices and has a small learning curve. Reports are good.
Version One - Swiss army knife of agile tools. Easy, full of features, great query tool to extract project data, need to ensure hosted service provides the performance you need
XPlanner - free, basic but non-evolving, easy for the team to use, less capable in the reporting department
Excel - works great, most people start with it and the file can be posted to a WIKI that can be downloaded and viewed by anyone
Consider the licensing. A number of the tools can post results in HTLM which can be read from a WIKI as a dashboard report. If you need to control access to the data then providing a license to the tools or providing a login to the WIKI should meet your needs.
Redmine, it is easy to use and contains enough features.
What specific problems are you facing with your current project management software that you want to address.. What specific flavor of agile are you moving to ?
The first bullet is kind of shaky... in that novice users should not really be doing project management. Other arguments read like 'MS Project should not behave like MS Project'
If you want a simplified tool for a product backlog which seems to be what you're looking for.. use a spreadsheet and see if it works out. If not, move to complex ones.
There's a similar thread in SO ... dupe or does this thread deviate significantly ?
https://stackoverflow.com/questions/426458/recommendations-for-project-management-software-for-scrum
I actually use Atlassian's JIRA for all my Agile project management. And with their recent acquisition of GreenHopper, they fully integrated SCRUM into the project management as well. This is only available in the Beta version right now though.
My team is using Rally. I also used VersionOne a few years ago, but I think Rally is better. I am not an expert in all features, but I think it does most of the things you need.
Don't even try MS project ...
Axosoft's OnTime
CounterSoft Gemini (at least take their 5 user license for free)
There's a new tool - Bright Green Projects. It allows you to capture and prioritize requirements, build estimates, manage iterations, track issues.. etc. Nice interface and really easy to use: http://www.brightgreenprojects.com