Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've come across the phrase 'sustaining software engineering' but don't know exactly what it means. There seems to be some DoD connection? Is it related to Agile Development?
Many in the software world define sustaining engineering as the bug fix team. While this is a part of the duties involved the sustaining engineering group should also be looking at the overall defect trends to help identify areas needing re-factoring. The focus of the group should be to not just fix bugs as they come in but to be the conduit back into engineering to ELIMINATE needless calls from customers. That might involve "works as designed" issues as well as product areas the customers just have a hard time understanding.
I believe "sustaining" is another word for "maintenance": it's what happens after software is released, i.e. support, bug fixing, enhancements ...
Sustainable Software Engineering: Consideration of the social and environmental effects of software projects in managing the project. Managing a software project in order to maximize the positive and minimize the negative social and environmental effects of the project.
Alternative (Sustaining): Consideration of the long-term support requirements during the design and development of a software project. The process of conducting the long-term support required when development is complete.
It's just a fancy way of saying "Software Maintenance Team".
Sustaining Software Engineering, at least in the cases where I've come across it, is the department responsible for implementing hot-fixes for released products, and handling customer service issues that the tech-support guys can't resolve on their own.
Related
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 5 years ago.
Improve this question
We are a small development team of 3. We are responsible for the design, development, test, and publish of each software application. We also provide software support, and deal with any issues the users may have, as well as bug fixing.
At the moment, each developer is solely responsible for seeing a project through from start to finish. So they will discuss with the client the requirements for the software. They will plan, design, and develop the software (both front-end and back-end). And they are responsible for testing and bug fixing.
Is this a development process that is recommended or should each developer be designated a number of tasks on each project?
I have been thinking of applying SCRUM principles to our development process but not sure how effective they would be. From what we do I gether that we are already working in an agile methodology with short iterations, and requirement discussions with the client?
Would you recommend SCRUM for our environment? How do other small teams operate?
It depends what is your purpose: implementing Agile just because it is the newest 'fashion' might prove to be very costly for your existing business.
In my experience (almost 15 years, now) it is better to implement Agile all around the company, not only at Tech level (or DevOps as they are now calling it).
If you implement any Agile method in a development environment than you simply get a bit more efficiency in that environment, only! A coder can not write more than that number of lines a day. Than, because the rest of the business is still at 'waterfall' your development side becomes a bottleneck by having to lag because of the rest...
In your particular case, perhaps it would be a good idea to get together with the developers and ask them: Agile or status quo? Once ALL of you agree for Agile than just go for it - first do it by the book and after a few sprints just start adapting what you need to your given situation. Perhaps a bit of pair-programming, a bit of cross-collaboration etc At the end of the day you are only three people: how difficult can it be to obtain consensus? funny
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Does anybody know what large companies are currently using agile iconix process??
The only ones I know are the one I could find on the ICONIX Software Engineering corporate website:
Case studies: see how ESRI Professional Services, Virginia Department of Motor Vehicles, and Large Synoptic Survey Telescope are succeeding with ICONIX Process
I may be wrong but to me, the ICONIX methodology isn't really widely used and it
looks more like a way to sell their Enterprise Architect product.
And personally, I never had big successes with too much UML centric approaches (à la MDA).
I like the process and used it well in several projects. I just want to give some of my thoughts on it:
Iconix is based on domain driven design. Domain comes first. This is fine, however we need to be aware of a boundary conditions. To put is simply, domain driven design works for the relatively complex projects. There may not be a domain model as design pattern at all since it may not be the best choice for every system.
Iconix assumes sophisticated deisgn. Not every project needs it and not every project has developers capable of absorbing it. There are tons of data-centric or purely data manipulation applications out there.
No community, stale web site. I don't know of anybody who uses the process.
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 6 years ago.
Improve this question
in software engineering should a contract draft be reviewed by software developers? or it should be left to legal department and to management?
The contract is usually of little consequence to the software developers. In my experience it's unusual for a contract to be reviewed by software developers, but is often reviewed by (or at least made visible to) managers of one type or another within the engineering department. The main points of interest for them would be the deliverables, the dates, any penalties and the maintenance/support offered.
The software specification (which can often be an appendix to a contract) should most certainly be seen by developers, but actual review (sign off and/or providing feedback prior to the contract being signed) is often limited to architects, product managers, project managers, technical leads and similar more senior roles.
This will of course vary a lot from company to company and depending what sort of area the software is in, whether it is bespoke software or another roll out of an off-the-shelf product, etc.
probably a good idea to do a sanity check of any deliverables and scoping or any hard to achieve requirements. - hopefully these could be seperated from the contract itself for a review.
Depends on the situation and your organization, but it can be helpful to have the engineers or engineering managers who are familiar with the code review and make sure you aren't misrepresenting ownership or rights if you are using third party and/or open-source libraries and code.
That really depends on how the contract is written. If the details of what needs to be delivered are integrated into the contract, that should be reviewed by software developers. Often times this is just an exhibit attached to the contract. In that case, you would just want to review that exhibit. The software team should not be worried about the penalty clauses, indemnity clauses, etc. which make up the bulk of the contract, but should be about delivery dates and specifications.
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 5 years ago.
Improve this question
We have a huge debate in our organisation to use AGILE in ERP projects. Can anyone give an example of a successful implementation as such?
Here are some papers and websites that you might be interested in:
Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell About It
Agile ERP: "You don't know what you've got 'till it's gone!" (Requires IEEE Xplore Subscription or article purchase to view)
Agile Project Management Methods for ERP
Agile ERP
I'm not that familiar with building ERP software, but from what it seems, they appear to have a few things in common. ERP software is large in terms of features and scope and development often takes a long time. I believe that Agile principles might be of value here, even if you aren't using full-blown agile methodologies.
The central tenets of Agile are rapid delivery of working software, accepting late-changing requirements, and close cooperation between the business and users and developers. A highly iterative approach to building an ERP system and close collaboration between the users and the developers to continually add the features that add the most value seem like it will yield the most bang for your buck.
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
A few years ago I have worked on a green field project where we did Extreme Programming. I also see a lot of people mention the Scrum methodology.
Could someone tell me the main differences between Scrum and XP?
Scrum is a software development methodology, XP is a programming practice. Both are "agile" techniques and are often used together.
Scrum outlines a process for identifying and cataloging work that needs to be done, prioritizing that work by communicating with the customer or customer representative, and implementing that work using iterative releases.
When my team first started experimenting with Scrum I found the Implementing Scrum website to be helpful.
Scrum is lightweight framework for building a product where there is high levels of complexity and uncertainty. It is NOT a methodology, as methodologies and practices can be chosen and used in conjunction to Scrum. It is not purely aimed at software development and can be used by other types of projects too.
When it comes to software engineering, Scrum does not define what practices to follow or methods follow as it does not want to prescribe what is best for that particular product and environment.
Many Scrum teams use several XP practices such as Testing, Feedback, Pair Programming and Simplicity.
The core differences
Scrum plans for a sprint and does not encourage change. XP is more open to change.
XP solicits feedback immediately and Scrum at least at the Sprint Review, however Scrum does not reject early feedback if possible.
XP focuses on programming, Scrum can be used in non software products
Scrum does not define how to do development, but many Scrum teams implement many of the XP practices
I've worked on both. Some of the main differences are that SCRUM focuses on the shorter more structured sprints, and prioritizes back log items. Some of the focuses of XP are more on paired programming, prioritizing the tasks, and more test driven development. Both work in iterations and both are flexible enough to handle a volatile changing project.
Scrum is one component of the Agile development methodology concerning the daily meeting held to discuss progress and XP is a different methodology stressing pair programming and test first development.
Scrum's main goal is to get estimations of how long development will take. XP is more about helping developers get things done as quickly and maintainably as possible.