I'm starting to design a software, the project manager gave me a list of modules the software needs, and he wants to see the interactions between the modules, ("not the flow", he said), but, I'm not sure of what he wants, (not sure if he is sure of what he wants)
¿any help?
Related
Suppose I make a class diagram for a social network system such as facebook. Should the notifications and discussion messages have their own classes?
I do really think they should. I made a full class diagram for such a system, with notifications and messages as classes, but my teacher told me to exclude them. Now I am confused.
This is a very interesting question for three reasons.
1. What’s the scope?
This is a core question for any work that you’ll do in your developer career: what’s the scope of the system?
is it just core social networking functionality of one to many communication, like you had on Facebook in its early days?
or is it a full clone of facebook, including its messaging features, but also its advertising and moderating features?
If it’s the first, you’ve done too much. If it’s the second, you forgot important parts.
Rule 1: Whenever there is a doubt about the scope, clarify it with your coach/manager/stakeholder before thinking you know what there is to do.
This will avoid you the frustration of doing work that is not valued. It will avoid your future customers the frustration of not getting what they’ve expected, or paying too much for something they didn’t ask for.
2. What’s the approach?
Whenever you model some software, there’s a purpose. Class diagrams can be used for different purposes. For example:
is it for analyzing the requirements? In this domain, you will certainly have a class for Post, Comment and UserAccounts as well as associations between them. But you’d limit yourself to the “problem space” and not address the software solution and its UI.
is for the design of the system? then it probably should address how the system will work, and give some more details about how the UI will interact with the domain object. This kind of diagram might be more detailed and show the “solution space”.
Rule 2: if asked to do some modeling, always clarify the purpose. In the real world, if not asked explicitly to model, clarify the agreed approach within your team.
3. Always clarify with the person the closest to the source
(the subtitle is already the rule).
Now, is the notification a part of the UI, because they shows posts that changed and it’s part of the solution design? Or is it part of the domain, because the need for notification is independently of the chosen software solution? And because moreover notifications need to be tracked and delivered, and the they will work differently on mobile apps (push) and on web pages (pull)? As you see there is some room for interpretation, and depending on his/her arguments, the teacher is not necessarily wrong.
Conclusion
As you see, it’s not right or wrong: there are a lot of nuances between the two. There are plenty of reasons that could justify your teacher’s position. I see at least two other unrelated ones:
to adapt the time of the exercise to the average capability of your class (which would be a good sign for you)
because the teacher already know the next questions and he/she already know that notifications will make it much more difficult (which would show that the teacher was nice).
My advice: trust your teacher, and in any case engage a discussion to understand the arguments, before jumping to quickly on unproven conclusions.
Key takeaway: requirement analysis and modelling are a communication activity more than a technical activity. Whenever there’s a doubt, engage discussion with your stakeholders before seeking advice from strangers on the net ;-)
I've recently switched to JIRA from another bug tracking system, and previously we were not using the "component" field. The project was pretty small, so it didn't seem to need it at the time. As the project is getting a little bigger, I'm finding that the component field may useful, but I'm not exactly sure of how to split the components.
For example, let's say I have a banking application and I am adding a feature to transfer money between accounts. That feature might be classified as an "Accounts" component, but it also would affect the user interface, as well as have some security issues associated with it. It seems like many issues will have this cross-cutting concern.
Is there a best practice for determining how to divide a project into components? Are things like "User Interface" and "Security" too broad?
I'm not sure this question has a single correct answer, so maybe it should be moved to a community wiki, but any insight people can provide would be helpful here.
Components are most useful if they have obvious default assignees for each one (component leads). Another approach is to wait for a while and use labels. See if there are common labels that your users like to use, and then create components in a few weeks for those labels.
A user creating a bug can add multiple components when reporting the issue. So they could select Account, transfers and security issue (or Loan, Payments, and security issue) as all components effected by a particular bug. Any combination of components can be put together so that the development team knows exactly where this bug is occurring.
We use the component field in our company mostly to cluster the issues in a meaningful way, so that reports to these components may give you feedback which part of your application development gets the most issues, or where the most changes (with the most resulting bugs) are happening. Sometimes, the components reflect the organization of a project, then the aspect of the default assignee is a valid one (as answered by #mdoar). But even then, the overview of the project is the most interesting aspect here.
I'm just learning about UML and am questioning how to define actors correctly. I know that actors perform role in the system and I don't have a problem determining human actors. My question is how do I decide what non-human, external components are actors on the system.
For example, in a home automation system a homeowner and a system installer would be actors. Would it be correct to name a door sensor or a coffee maker an actor? These components receive signals from the main computer module and use cases could be written for actions taken on them (i.e. turn the coffee maker on/off).
Is the main computer/server the "system" or is the system made up of the collection of the computer/server and all of the components (lighting modules, coffee makers, door sensors)?
I think that you must first define system's boundaries, it will be then more easy to understand external actors but keep in mind that actors usually treated as black boxes.
For example if the automation system finds out that the food supplies are low and need a restock it may initiate an order perhaps on an online service; in this case the online system accepting such orders is an actor, you don't need to know how it will process the order, you as a developer of the automation system need to know it's public interface in order to interact with it.
An actor is someone or something (another system) that interacts with the system you are trying to develop. More formally an actor initiates use cases.
#Stef - An actor can also assist the primary actor to achieve the stated goal of the use case. That would be the case with the online service from your example. The online service wouldn't initiate any use cases here, but in receiving the order, it becomes a secondary actor to the Order Food Supplies use case.
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
Is there any way to protect my code during development so that if a developer leaves my company they are unable to access files in my project?
This is especially important with TFS where the project is downloaded locally, cached, and available for offline use. Ideally the code would be unreadable if they did not have a valid Active Directory user ID.
Even if this idea is not possible, I'd like to learn of any practical deterrent you can think of...
You have to extend some form of trust to your developers. If you can't trust them not to take source code with them, how can you trust them not to build back doors and the like into your systems?
Moreover, if they're going to work on code, they're going to need access to it, and if they get access to it they can almost certainly copy it. You can try to limit it, but it's you trying to outthink in advance a group of people who only need to find one mistake you made. Besides, overtly distrusting your developers isn't going to help you anyway.
Are there actual trade secrets built into your code? If so, you might want to rethink that. If not, how much harm will it do in somebody else's possession? They can't legally use it, and the developers that leave will often be able to write something similar anyway.
For this, you want legal protection, not technical.
Assuming they can read the code and compile it while they are there, there's not a lot you can do (unless you ban USB sticks, CR writers, scan all their email etc, and even then they'd find a way of defeating that).
Cover it in the employment contract, make it clear that if the code turns up there will be legal action.
(I've had this happen to me in a past life - an employee did take the code with him. We knew due to an error he made in doing it, and we sent a letter from our laywers pointing out the consequences of him revealing the code to anyone else. It seemed to work)
If you are afraid of losing a code as a whole (rather than the employee copy-paste part of it)...
With your source code management system (you have one, right ?), you can probably have some hooks so that when the user gets the code, part of it is a binary file that is dedicated to only that user and is necessary for the code to compile correctly and run correctly... if you push to the extreme, that will mean having the right hardware system (TPM, hardware keys...etc).
So after you have dealt with all the paperwork as Paul suggests for example, if ever the code leaks anywhere, you can track who is at fault (and knowing that would probably deter anybody to actually even try)
All things considered... no (especially if the project is stored locally as you mentioned). If a developer has access to source code, they have the ability to steal source code. IANAL, but to deter this sort of thing, you need a lawyer to draft up a non-disclosure agreement (NDA) and get your developers to sign it.
From Wikipedia, an NDA is:
a legal contract between at least two parties that outlines confidential material, knowledge, or information that the parties wish to share with one another for certain purposes, but wish to restrict access to by third parties. It is a contract through which the parties agree not to disclose information covered by the agreement.
This really isn't an crypto question. But there is an answer.
1)You should limit developers and only give them access to source that they need to get the job done. This the security principal of "least privilege access". Store binaries of libraries or the executeables in source control if need be.
2)Force all developers to sign a Non-Disclosure contract. Higher developers that you can sue. For instant defending this contract in India is more difficult than defending it in Indiana.
There are ways to secure your entire development environment so that so programmers can keep or take souvenirs of what they are working on. Take a look at www.chaperon-secure.net for possible solutions from secure development environment to vaulted source code repositories.
You can somewhat reduce the risk of code theft if your application is cleanly built into components/modules/plug-ins. The dev would only be given code access to the components that they work on, and compiled code for the rest of the application. I am, of-course, assuming that it's only worthwhile to steal the application as a whole and not just a handful of components.
On the other hand, you would be surprised that code itself is not always as valuable as you would like to think. If there is no sensitive IP in the code that can be directly resold, then is your dev going to just recompile and go head-to-head with you with their own application?
I repeatedly find that establishing user requirements is one of the hardest parts of my job. This is for several reasons, for example, lack of shared technical vocabulary, incomplete understanding of domain on my part, inability of user to 'imagine' completed UI / product, etc etc.
Since this appears to be an ongoing challenge for me, has anyone here had a 'eureka' moment that has really helped them with this part of developing? For example, I have heard of the book 'Domain Driven Design', but not read it yet. Has anyone found a book, online resource of piece of advice that has really turned things around for them?
I won't aspire for eureka experience, however, if you are interested in DDD, which is about establishing common language for you and the users (among other things), than if you don't have access to the book, look for the Domain-Driven Design Quickly on DZone.
Generally speaking, any time user cannot imagine the thing and therefore state proper requirements, go for the prototyping (if you can). Recently I was pleased by really super simple tool which is a Firefox extension called Pencil, which enables easy and quite fast prototyping even for non-programmers. It is far from perfect, but it enables you to create own components and it is extensible.
Are you creating the user requirements on your own or are you actually interacting with the user to generate the requirements?
If you are creating a piece of software without a customer then starting with a simple high-level mock-up of what I want to create is where I will usually start and will formulate my User Requirements how I think a user would use the software.
If you have a customer I would suggest breaking the software into smaller modules (manageable chunks) and sitting down with the user to talk to them, step-by-step, how they want the module to function.